Re: [dnssd] Second WGLC for draft-ietf-dnssd-srp

[[e-mail]]

Hi folks,

 

I’ve read the SRP document and believe it is ready to proceed to the IESG.

 

I do have some minor nits and suggestions below.

 

Thanks to Ted and Stuart for all the work so far!

 

Gabriel

 

-------

Section 1, introduction.

 

DNS-SD is used without first defining it. Suggest this:

 

OLD:

DNS-Based Service Discovery [RFC6763] is a component of Zero Configuration Networking

NEW:

DNS-Based Service Discovery [RFC6763] (DNS-SD) is a component of Zero Configuration Networking

 

 

Section 2.1.1:

 

"Hosts that support SRP Updates using TLS use the "_dnssd‑srp‑tls._tcp.<zone>" SRV record instead."

 

Besides the TLS case, any clarification on updates for other DNS-over-foo cases such as for DTLS or QUIC or DNS-over-HTTPS? Privacy section already has references to DNS-over-TLS and DNS-over-DTLS, but nothing on DNS-over-QUIC (rfc9250) yet.

 

 

Section 8.1

 

OLD:

IANA is requested, with the approval of IAB

NEW:

IANA is requested, with the approval of IAB (per https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/)

 

 

 

References:

 

OLD:

https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03

NEW:

https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-02.html

 

 

 

 

From: dnssd <[e-mail]> On Behalf Of Nathan Dyck
Sent: Friday, August 19, 2022 08:07
To: Esko Dijk <[e-mail]>; David Schinazi <[e-mail]>; DNSSD <[e-mail]>
Subject: Re: [dnssd] Second WGLC for draft-ietf-dnssd-srp

 

I’ve read the document and see no issues above whats already been mentioned. I’ll be glad to see this published.

 

Best Regards,

 

-

Nathan Dyck

Chief Product Officer

The Nanoleaf Team

e: [e-mail] | c: 289-242-0016

 

Sent from Mobile

  _____  

From: dnssd <[e-mail]> on behalf of Esko Dijk <[e-mail]>
Sent: Thursday, August 18, 2022 10:15:59 AM
To: David Schinazi <[e-mail]>; DNSSD <[e-mail]>
Subject: Re: [dnssd] Second WGLC for draft-ietf-dnssd-srp 

 

WG members,

 

I read the document and believe it is almost ready for publication. If the below open issues would be resolved it would be ready for publication IMO.   After the open issues I also include here a list of editorial items/nits/improvements that should be considered but can equally well be fixed during the RFC editing phase. I.e. the editorial items don’t impact the WG’s completion of the document I think.  I don’t see any big changes needed, it’s all clarifications and minor fixes.  Another WGLC would certainly not be needed! Rather I’d like this document to proceed quickly if possible.

 

For constrained wireless mesh networks, this specification will be a key element for enabling service discovery in a lightweight manner while still integrating with the existing “mDNS ecosystem”. Thread networks are a good example of this.

 

Regards

Esko

 

*** Open issues

 

2.2.1

“The Service Instance Name MUST be referenced by one or more

      Service Discovery PTR records, unless it is a placeholder service

      registration for an intentionally non-discoverable service name.”

-> This bit is a fairly detailed requirement, with a hard-to-grasp exception case also. Why not include such requirements only in 2.3.x which anyway has all the formal rules? I thought 2.2.1 was more like an intro sketching at high level what it looks like, and 2.3.x has details. The MUST requirement is already present in 2.3.2.

The exception case seems not listed there – is that a bug?

 

“The SRP requestor SHOULD follow the advice given in Section 5.5.2 of [RFC8766]” -> this automatically makes RFC 8766 a normative reference, per the IETF rules for that. (Even if it was a MAY this would be the case. The point is that an implementer OPTIONALLY will use the rules and if so, 8766 becomes normative on how to do these rules. ) So, ok to make RFC 8766 normative?

 

2.2.3

“so there is no need for the server sending the SRP Update” -> “no need for the SRP requestor” ? “server” seems wrong here. Sorry this is almost a nit but I don’t think we should rely here on reader’s internal autocorrect… 

 

2.2.5.2

“So for instance, it might try

   host.service.arpa, then host-1.service.arpa, then host-

   2.service.arpa, then host-31773.service.arpa.”

-> here the domain should be “default.service.arpa”? If so, it must be fixed to avoid interpretation errors (does the implementation also need to be fixed for this?). If not, then there’s a bunch of clarification missing why “default” can be omitted here. (But I assume that doesn’t apply here.)

 

2.2.5.4

“Although [RFC2782] requires that the target name in the SRV record

   not be compressed, an SRP requestor SHOULD compress the target in the

   SRV record.”

-> This means RFC 2782 is formally Updated. The draft should indicate this in the usual IETF way at the top as “Updates: 2782”.

 

2.2.5.5.1.

The Method 2 of only removing the Host record is still a bit unclear – as explained in my previous email about “Host instructions with no address”. 

Text says “Therefore, it is sufficient for the requestor to send the Host Description Instruction” but the latter requires a “Service Description Instruction” to be present which contradicts the stated.

 

2.3.1.3

Last bullet - See previous email on “Host instructions with no address” ; it would seem we do have a case where the Service Description Instruction can be absent in the SRP Update – if lease-time=0.  All the host’s services would then get auto-removed.

 

2.3.5

“and can be either SUCCESS or SERVFAIL” ->

In the IANA registry it’s listed as NoError instead of SUCCESS. RFC 1035 calls it “No error condition”. So we could adopt ‘NoError’ ? (Since the original spec doesn’t use CAPS for the name)

 

4.1

See section 11 ref update.

 

“SRP registrars SHOULD also track a lease time per service instance”

-> this seems problematic to have as a ‘SHOULD’ because you can’t count on the SRP Registrar doing it properly.

E.g. if this is not done, you could get the following situation:

 

*	At time t=0, requestor registers service X with lease = 10 mins
*	At time t=5 min, requestor registers service Y with lease = 8 hours

*	At this time the Registrar extends the life of the host and all its services to 8 hours (since it doesn’t track lease time per service instance)

*	(Requestor expects at time t=10, that service X will time out)
*	At times t=10 min – t=8 hours, service X remains in the Registry unintentionally.

 

So better is to either do it (MUST) or don’t do it at all. In the first case, partial updates like in the example above and below are possible. When not doing it, partial updates should typically be discouraged since it gets tricky to get it right.

 

Another example of ‘partial update’ enabled – this situation works even when the SRP Registrar doesn’t track lease time per service :

 

*	requestor registers service X at time t=0 for a lease time of 8 hours ; 
*	at t=1 hour it registers service Y for a lease time of 1 hour.
*	at times t=1 to 2 hours, both services X/Y are active. And at  t=2 hours, both services X/Y and the host will time out at the same time if the requestor doesn’t renew before that.

 

So in this case the first lease time 8 hours applies to the host and to service X, and the second 1-hour lease time applies to the host and to service Y, not directly to service X (which still has 7 hours to go) but due to the host removal service X is also removed at time T=2 hours.

 

What is perhaps missing/unclear in the spec if the SRP requestor is even allowed to do such fractional updates where the SRP Update doesn’t contain all the registered services.  I don’t think this is mentioned anywhere.

 

“The times may be

   shorter or longer than those specified in the SRP Update; the SRP

   requestor must honor them in either case.”

-> Is it an idea to also require (“SHOULD”) a configuration mechanism here just like for the TTL to set a Min and Max ?  For example, in a network with sleepy devices a longer allowed lease time Max could be configured on the SRP Registrar.

And if a network is getting busy with registration traffic, the Registrar could be reconfigured to have a longer Min lease time.

 

8.1

Should we say anything about the subdomains under “service.arpa”? In this document we use “default.service.arpa”, but what about in the future when someone wants to use “myname.service.arpa” etc ? Is there a registry, or is an RFC needed to define these names?

Maybe this is more of a question than an open issue for the document.  But if we know how this is handled we could just mention it briefly.  I had a case in the past in IETF where a registry was forgotten where it would have been handy.

 

11.

Ref update https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03  by https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-update-lease-02 

 

12.

RFC 8310 is informative, however it defines a profile that updates 7858 normatively. So shouldn’t it be in ‘normative’ section 11? If not, does that mean that nothing of the profile of 8310 is used in any implementation?

(Maybe it doesn’t matter much, since 7858 is normative and that one is being automatically updated by 8310 whether we like it or not.)

 

RFC 1035 needs to be normative – impossible to implement SRP without using e.g. the record formats defined there.

Same for 2782 (need SRV records to implement), and 2181.

(Again I may be wrong here – maybe 2181 is automatically normative if we make 1035 normative and it doesn’t matter where it’s placed.)

 

 

 

*** Improvements/nits/editorial

Entire doc

“SRP Update” / “SRP update” used interchangeably without apparent reason(?)

 

 

1.

First occurrence of “registrar” does not define the term. There’s also no terminology section to look it up. This term should be defined in Section 1 ideally. Section 2.0 doesn’t really define it either, it only mentions it in terms of “most likely”.

 

2.

“SRP requests” -> better to use SRP Updates here, since “SRP requests” is only used once so is probably not the intended term. Or, “SRP Update requests”.

 

2.1.1

Mention “default registration domain” first and then calls it “default registration zone”. Is this correct? 6763 calls it only “domain”.

Nit: “using SOA queries [RFC8765]” -> it would be good to refer to a specific section here, e.g. 6.1

 

2.1.3

“The reason for these different assumptions” -> “The reason for these different variants”

Nit: The standalone words “power” can all be changed to “energy” to be more correct.

“By requiring the use of TCP,” -> clarify that this applies to full-featured hosts only. Is that intended, or do constrained devices also require TCP?

 

2.2 

“We will discuss … and how to maintain the information … “ -> part of the “maintain” part is in section 4, so it’s a bit strange to announce it here as part of 2.2.x. Maybe add a forward pointer to 4 here also.

 

2.2.3.1.

Last bullet -> add “.” at end

 

2.2.4

“TSIG protocol” -> add informative reference to [rfc8945]

 

2.2.4.1

“using DNS-SD Registration protocol” -> “using the DNS-SD Service Registration Protocol”

“First-Come First-Serve” -> “First-Come First-Serve (FCFS)” – there’s a need to introduce the acronym here

 

2.2.5

Title “Service Behavior”  -> shouldn’t this be “SRP Requestor Behavior” ? Since we just before talked about “registration service” the term “service” here is unclear.

 

2.2.5.1

“"factory reset."" -> “"factory reset".”

 

2.2.5.2

“Service Description Records” -> set ‘R’ to lowercase

 

2.2.5.3

“ The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records [RFC6763] uses the LEASE field”

-> we could clarify that it also holds for other record types. E.g. for everything that’s not KEY, the LEASE field is used. 

Since 2.2.1 specifies that other record types may be used for Service Description and 4.1 specifies this too. Maybe it’s enough we say here “DNS-SD PTR, SRV, A, AAAA, TXT and other non-KEY records” or give a pointer to 4.1.

 

2.2.5.5.2

“these will be seen as a single Service Description Instruction” -> could clarify what “these” refers to here. I didn’t immediately parse it. I assume it refers to both mentioned *-RRset updates. So “these updates will be seen … “

 

2.3.1.3

“hostname being updated by this update” -> more correct seems “hostname being updated by this instruction”.

 

2.3.2

“Every Service Description

   Instruction must have that Host Description Instruction as the target”

-> MUST 

 

“The target of the SRV record in every

   Service Description Instruction MUST be the single Host Description

   Instruction”

-> “ … MUST be the hostname used in the single Host Description Instruction”  (more correct)

 

“RCODE=REFUSED”

-> for style consistency, call it “REFUSED RCODE”.

 

2.3.3

“present in the Host Description to which the Service Description refers”

-> “present in the Host Description Instruction to which the Service Description Instruction refers”

 

2.3.6

“In order for the registrar

   to add a reverse mapping update, it must be authoritative for the

   zone or have credentials to do the update.”

-> “the zone” here is a bit unclear. We could say “the associated zone” to indicate the zone that’s to be used for the reverse mapping update? Without going into unnecessary details.

Otherwise it could mean “the zone of the SRP Update” which isn’t intended I think.

 

“The registrar may also have a dictionary of names”

-> MAY

Making it normative is better here to force a requestor implementation to consider this case of (unexpectedly?) getting RCODE YXDOMAIN for a valid SRP Update.

 

4.1

Section title should also mention the “lease time” concept – it is such an important part of this section.

E.g. “Lease Time and Stale Data Cleanup” or “Cleaning Up Stale Data and Lease Time”

 

5.1

“validation must be enforced by every router on the path from the

   Constrained-Device Network to the unconstrained portion of the

   Network”

-> it’s strange this this only considers constrained-network scenarios. Needs some rewording e.g.

“validation must be enforced by every router on the path from any potential SRP requestor to the SRP registrar.

   In case of a router that is a constrained device, this validation is recommended but not required.”

 

Perhaps 6lowpan Routers generally won’t validate all this; while 6lowpan Border Routers could do more extensive validation.

 

8.2

Second paragraph -> still a grammar error in there

 

8.3

Second paragraph -> same grammar error. There’s also an extra dot ‘.’ After <domain> here and not in 8.2, why’s that?

 

 

 

 

 

From: dnssd <[e-mail]> On Behalf Of David Schinazi
Sent: Tuesday, August 9, 2022 00:45
To: DNSSD <[e-mail]>
Subject: [dnssd] Second WGLC for draft-ietf-dnssd-srp

 

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