IETF Logo Mail Archive

Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)

Kangping Dong <wgtdkp@google.com> Sun, 20 December 2020 05:51 UTC

Return-Path: <wgtdkp@google.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C1E3A0ACB for <dnssd@ietfa.amsl.com>; Sat, 19 Dec 2020 21:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.256
X-Spam-Level:
X-Spam-Status: No, score=-17.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.342, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrUgqNHHi13h for <dnssd@ietfa.amsl.com>; Sat, 19 Dec 2020 21:51:53 -0800 (PST)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1FAC3A0AC8 for <dnssd@ietf.org>; Sat, 19 Dec 2020 21:51:53 -0800 (PST)
Received: by mail-yb1-xb34.google.com with SMTP id w135so5883550ybg.13 for <dnssd@ietf.org>; Sat, 19 Dec 2020 21:51:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3fuycAhubvv0P112UEk9IT1bywcR/Oa+6QAv2vqlrZ0=; b=dBfsccLCuRYpBAd9XA2Zhtvgbdrx5uIq2E4XwX0nrZebk86FxWgJNMd3zAOEH6vmYc D0zwSr9YsivXkHp52W7Wp43Uw51zWfWji5ekLoB4rG5v0KDhCE7qs/b+LCRBXjw4dXvz mwTpyO1oeuluSZvve0H4+u3g5UoVtJz6s1hUi5zn8KvZEuNcPDd0jGGQJbMhm1yfRobi LhfVy2sn0WI+SeXt8VjXo678mRkvlKRM1v2CoZF4tpa+Q7keYq2nBNZ2l6rJlMR2Fzdg l1kMLN90T8aGOsVoqsotlJtbC6yG8LPoGfRHz6s+3//pcUurPXittIeDIUIDAUEksXaS VYqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3fuycAhubvv0P112UEk9IT1bywcR/Oa+6QAv2vqlrZ0=; b=pPa4tnQ4d/4YxmOpogQmKSx+M1ORbQg7K4o2eHgalfvxQtdlt9Jd6YpxXAdma2xmR7 jJZ8wY/eibpJk1CripmL9JP4fUKLKlISxGz7JA/ZsXgzdDwEPYdrt+qGmJ2K93B3B3i3 6nr5xwMF1DEBDlquO+/xLVIateggQJJ+ck+DeW6zkb+Uzv9YgwobKiXDAdFR6KHieRN5 saOVEXPCGWbYvAmtrBSGzhztyqk4is3PKAZKST4dovfqmtEf68qhE/fq1i45IqgT3fXZ CZchSrPHs+Sw/t/hRc3Fuzd1fEPW+6ejdx556UIR60eSwsZJQF3tgrqOlhXq7T79NBe/ L12w==
X-Gm-Message-State: AOAM530wU4qc6uwEdfDP/aYAu0zveeSB6HgZwgynwDkx36Z57cs+jEiX /eUW1QU4dKhmo0C3oa4SPvjljT8jgG22cTz2K9Ew/A==
X-Google-Smtp-Source: ABdhPJxlSf3sOwtKGFAqwHn7sYOCaW8F63qPdL7+BL15fgGW0hKWgwz2xcIogqVXAV0ooszvhItaw6Y5oFHIj+tn+cs=
X-Received: by 2002:a05:6902:706:: with SMTP id k6mr16414031ybt.232.1608443512789; Sat, 19 Dec 2020 21:51:52 -0800 (PST)
MIME-Version: 1.0
References: <CACce4dTbWCVwBityepJpb5FF4Rv43+DUev_0Ka+rVT9exZrJzA@mail.gmail.com> <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <CACce4dQZ708aaMdvmwhEurHDSdFAvLbzwpDWz=viig_2cX75Dw@mail.gmail.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <CAJ5Rr7bDSMv1uPDPXppG9e4OUEU7oriK9tVKD20=P3Kgb2q=0g@mail.gmail.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <CAJ5Rr7Yw33y2k=wo-ZXzFNP77=bucRcr2LxJxf+98e5oqK+fsw@mail.gmail.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <CACce4dToa2+FiYgzp5AvZjO7-UfHy5VSSZ4ED+PkHMVPBZTQAA@mail.gmail.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> <CAJ5Rr7ZmVWRp8H1Kg2QVXFJKnrUK09J2iPHsVTDvSxFioAznUQ@mail.gmail.com> <CAGwZUDtJMRXrTq4+3EMKQM_f_m6Tv+Nmxevkdak-A3yaskbPaw@mail.gmail.com>
In-Reply-To: <CAGwZUDtJMRXrTq4+3EMKQM_f_m6Tv+Nmxevkdak-A3yaskbPaw@mail.gmail.com>
From: Kangping Dong <wgtdkp@google.com>
Date: Sun, 20 Dec 2020 13:51:16 +0800
Message-ID: <CAJ5Rr7YTMU1dJdgf6Jgsioefhuu3pp_BaK8Q0RJ0nmhEk-oF2Q@mail.gmail.com>
To: Jonathan Hui <jonhui@google.com>
Cc: Ted Lemon <mellon@fugue.com>, Abtin Keshavarzian <abtink@google.com>, DNSSD <dnssd@ietf.org>, Rongli Sun <rongli@google.com>
Content-Type: multipart/alternative; boundary="00000000000038f65305b6def0ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Zib2ns4rMGDxGkjKUXBpGBUOuL4>
Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Dec 2020 05:51:56 -0000

>
> RFC 6763 Section 6.8 Service Instances with MultipleTXT Records
> <https://tools.ietf.org/html/rfc6763#section-6.8> discusses this.
> However, the end of the referenced section also states:
>
>    Future protocol designs should not follow this bad
>    example by mimicking this inadequacy of the LPR printing protocol.
>
> Thanks Jonathan, I missed that section.

So I guess the question is whether we can/should mandate this future going
> forward in SRP?
>
Exactly. I would prefer we explicitly disallow multiple TXT records for
SRP.

BRs,
Kangping

On Sun, Dec 20, 2020 at 12:14 AM Jonathan Hui <jonhui@google.com> wrote:

>
> On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong <wgtdkp@google.com> wrote:
>
>>
>> 2. What's the use case of supporting multiple TXT RRs?
>> in section *2.3.1.2. Service Description Instruction
>> <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-service-description-instruc>*,
>> we have:
>>
>>> zero or more "Add to an RRset" TXT RRs,
>>>
>>
>> Are there real use cases that we need more than one TXT RRs? What is the
>> expected behavior
>> for the advertising proxy to publish this service with multiple TXT RRs?
>> (I think DNS-SD requires
>> a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated
>> to form a new TXT RR?
>> If there is no such use case, should we require a single TXT RR? It will
>> be easier to implement on both
>> client and server side and consistent with DNS-SD. thoughts?
>>
>
> RFC 6763 Section 6.8 Service Instances with MultipleTXT Records
> <https://tools.ietf.org/html/rfc6763#section-6.8> discusses this.
> However, the end of the referenced section also states:
>
>    Future protocol designs should not follow this bad
>    example by mimicking this inadequacy of the LPR printing protocol.
>
> So I guess the question is whether we can/should mandate this future going
> forward in SRP?
>
> --
> Jonathan Hui
>
>

v2.23.0 | Report a Bug | By Email