Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease

[[e-mail]]

Hi folks,

 

I have read the Update document and I believe it is ready to advance to the
IESG.

 

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

 

Gabriel

 

From: dnssd <[e-mail]> On Behalf Of [e-mail]
Sent: Saturday, August 20, 2022 11:32
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease

 

I have also reviewed this document in detail and consider it valuable and
ready to publish.

 

I did notice one typo and one minor grammar issue.

 

The last line of section 5.2 (just before 5.2.1) includes the word "initil".
That should be "initial".

 

Section 9 (Acknowledgments) includes this sentence:

   Thanks to Marc Krochmal and Kiren Sekar to their work in 2006 on the
precursor to this document.

I believe this should be "for their work" not "to their work".

 

Thanks,

 

Steve

 

From: dnssd <[e-mail]> On Behalf Of Nathan Dyck
Sent: Saturday, August 20, 2022 10:50 AM
To: Esko Dijk <[e-mail]>; David Schinazi
<[e-mail]>; DNSSD <[e-mail]>
Cc: Ted Lemon <[e-mail]>
Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease

 


Caution: This e-mail originated outside Infineon Technologies. Do not click
on links or open attachments unless you validate it is safe
<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati
onsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx> .

 

I've reviewed. Looks good to publish

 

Nathan

 

-

Nathan Dyck

Chief Product Officer

The Nanoleaf Team

e: [e-mail] <mailto:[e-mail]>  | c: 289-242-0016

 

Sent from Mobile

  _____  

From: dnssd <[e-mail] <mailto:[e-mail]> > on
behalf of Esko Dijk <[e-mail]
<mailto:[e-mail]> >
Sent: Friday, August 19, 2022 8:17:22 AM
To: David Schinazi <[e-mail]
<mailto:[e-mail]> >; DNSSD <[e-mail]
<mailto:[e-mail]> >
Cc: Ted Lemon <[e-mail] <mailto:[e-mail]> >
Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-update-lease 

 

Hi all,

 

I reviewed this document in detail and have only 1 open (technical) issue on
it, see below.   This is followed by a few minor review comments.

Based on this, I believe the option is quite useful, and the document is
ready for publication after the open technical issue is resolved by the WG.

 

Best regards

Esko

 

--- Open issue

4.2

Based on the stated requirements in 4, a server developer could assume the
following scenarios are okay:

*	requester sends the basic Option (lease time only), and the server
responds with the extended Option (lease / key-lease separately)
*	requester sends extended Option and the server responds basic
Option.

A client developer could assume based on the same text that one or both of
these scenarios are not okay / prohibited.

 

To guarantee interoperability for such cases, we need to say in 4.2 either
that a server MAY do this, or alternatively that a server MUST NOT do this
responding with a different option format.  It could be even a rule that the
server can "lengthen" the Option but not "shorten" it.

 

I don't have a preference on the solution chosen as long as we pick
something.  Noting that for the client's point of view, if the server always
responds with the same Option Format it is simpler to implement.

On the other hand this reduces the flexibility of the server - e.g. suppose
the client asks for 1 week lease (short Option format) and the server can
only grant 27 hours LEASE but can grant 2 weeks KEY-LEASE - then the server
would like to respond with the extended Option format.

 

 

---- Minor review comments

 

General

EDNS0 vs EDNS(0) - is there a reason for the different spellings?

 

5.1

"The LEASE interval indicated in the Update Lease option applies to all
resource

   records in the Update section, except that . "

-> "in the Update section" may be unclear here. There's an Update section in
the request, but is there also one in the Response (I assume not necessarily
)?

-> Easiest here would be to say maybe:

"The LEASE interval indicated in the Update Lease option applies to all
resource

   records in the Update section of the Refresh request, except that . "

 

5.2

"A requestor that intends that its records from a previous update,

   whether an initial update or a Refresh, MUST send a Refresh message"

-> grammar error in sentence -that intends what? E.g. is it

-> "A requestor that intends that its records from a previous update,

   whether an initial update or a Refresh, remain  active MUST send a
Refresh message"

 

 

 

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

 

Hi DNSSD enthusiasts,

 

As promised during our meeting at IETF 114 two weeks ago, we are starting a
Working Group Last Call (WGLC) for draft-ietf-dnssd-update-lease. As a
reminder of our timeline, this document was adopted by the DNSSD WG in
September 2021, folks made comments during that adoption call, and those
comments were addressed by the authors in July 2022. Additionally,
progressing this document is required for us to publish
draft-ietf-dnssd-srp. This WGLC will last for two weeks until 2022-08-22 at
23:59 UTC. We're interested in hearing whether folks have read this document
and think it is ready for publication. We're also interested in hearing from
folks who think the document isn't ready, or who see issues that need to be
resolved before publication.

 

The latest draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/

 

Please send responses to the DNSSD list as replies to this email.

 

Thanks,

David and Chris