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

[Ted Lemon <[e-mail]>]

On Aug 23, 2022, at 6:24 AM, Esko Dijk <[e-mail]> wrote:
> I reviewed the new (Github) text.  Most comments are well addressed, here a few remaining points:
> 
>  
> 
> New section “Subdomains of 'service.arpa.'” -> this section reads as if it should be placed within the “IANA Considerations” section as a sub-section, or at least be referenced from the IANA section?  Now it is outside it and not referenced.

Yup, this was 2am brain. I meant for that to be a subsection of the IANA considerations section, but didn’t actually check to see that I’d put it in the right place.

> “increase the power required” -> “increase the energy required”

Aah, I missed that one. Thanks.

>  
> 
> >> -> “present in the Host Description Instruction to which the Service Description Instruction refers”
> 
> > why
> 
> Oops, maybe my text proposal was actually not good! We can leave it as is.  One Instruction also doesn’t reference another Instruction, but references data.
> 
> One trigger was that the terms “Host Description” and “Service Description” are used and gradually introduced in the document, but there’s not a formal/specific definition. The draft overall suggests that a “Host Description” can mean the data in the Host Description Instruction, or that it can be data in the SRP Registrar’s local database (which resides there as a result of processing previous Host Description Instruction(s)). Similar for “Service Description” – may be the data of a Service Description Instruction, or data about a service already present in the database.
> 

Sorry, this was 2am brain again.  Your reasoning above makes sense, but in fact I really did mean to distinguish between the service description and the service description instruction here.
 
> > However, you’re right that this is a problem, because if it does a pattern match, EXPLETIVE-4387 is going to fail just as badly as EXPLETIVE did. So maybe it should return REFUSED in this case.
> 
> Yes, I agree with “Refused” in case the adding of new numbers at the end by the SRP Requestor (e.g. EXPLETIVE-3, -4, -4387 etc) would not make any difference for the name filter.  Seeing “Refused”, a Requestor knows that it could retry with a completely different name, in this case. (Contrasting to YXDomain:  that signals the requestor to try with changing/adding some number at the end of the name i.e. retry with a similar name.)
> 
>  
> 
> I do think that if the server has a very specific name filter (e.g. on “EXPLETIVE-1*” only) it could just configure for that the YXDomain answer, triggering the Requestor to try again with another name (e.g. “EXPLETIVE-2”) and that would likely succeed.   So that would be allowed, but seems a corner case that we don’t need to spend any text on in the draft; something an implementer could just use if required.
> 

Yeah, I think that an implementation that does that can return a different answer on the basis that it’s a reserved name, but the text should account for the more useful test case, since if an administrator really does want to avoid publishing embarrassing names, a pattern match is going to work a lot better than a list of specific domain names.
 
> > That title doesn’t make sense. We aren’t cleaning up the lease time. I this this is fine as is.
> 
> Right, it can easily be read in a way that makes no sense. (I was intending the other way.)  So let’s keep as is.
> 

OK, thanks!
 
> > Send text?
> 
> I don’t think we need additional text for 6LoWPAN Border Routers (6LBRs) here, the phrasing is generic currently for “routers” so IP routers, which includes such 6LBRs.
> 

OK, sounds good.

Pull request here: https://github.com/dnssd-wg/draft-ietf-dnssd-srp/pull/12/files