[netmod] Re: [netconf] Re: Re: Default statements on udp-client-server groupings

Per Andersson <per.ietf@ionio.se> Sun, 22 September 2024 01:21 UTC

Return-Path: <perkietf@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88DC15106A; Sat, 21 Sep 2024 18:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.655
X-Spam-Level:
X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTOVeqlERQYO; Sat, 21 Sep 2024 18:21:28 -0700 (PDT)
Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773BFC14CE24; Sat, 21 Sep 2024 18:21:28 -0700 (PDT)
Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-2d8a4bad404so270372a91.1; Sat, 21 Sep 2024 18:21:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726968088; x=1727572888; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xDevyWzCC1fKdlJmvPQqKkWQpgdKgmDqFsxUlBuWF+E=; b=EqcZiYbX+xh5lmuELSpYNdCbYXj6rIR0fJdO+eXf31AsYVtaz2WTbLpz/Hhj1m+pBX t7+6izcXwwF3iGNJ7qlHo/MfaKEtxLKgdN6m3fq+Gwkx5SA5YEIMenOBloClMro1pkPL b7GUWNY37fyCfPtguP5pZsTSZVtEhUOnbHZ10uCJFJXqDtcr0Lqe8ytrTN1l0grgazp/ QgBhmuQ96jZdQizKBkzuKhuxO5oP2mFOSevHj16k0DI07um5tyEQdQ4eSOhLmgAHt/c+ IIdifjwDoSYClg46k/hV8rtcBO8S3FKeIXK7KlCTHVv7PHin0vZxA+/vip6Pi1cakLBM jjvA==
X-Forwarded-Encrypted: i=1; AJvYcCUI27CfKgX8pNq9nwuID+zmMMopDMeA+JCAWsz4pLwhUi6YjaKp6LD3BWRnOtKSKnHyQUtL+/VSuudV+VB/oEe60FwqrPwfpmGcKczQrluziaVFkzaKbgixlo3TPw==@ietf.org, AJvYcCUvbLU7FG04v4C2JrSttHVxUzCDHIHUkmD/4DchtOjBBxjXwQnDUQBoAVPVqA2xLijzGuJ3OUYdmw==@ietf.org, AJvYcCXCkDVHcyzyXrBZVcWTkCpkRDjUlbwMsgt3hmdLGE7p4f0UZ7YVOyMW6lnatkaMqZip/DkrfbpO@ietf.org
X-Gm-Message-State: AOJu0YwYr1/I4cptUSCdCBxNzlVGPCalMhER0LyVHWey1xkBE6jtzapr 9xzhOWsO89q39tog+U3slpB2sbFOOGg09yipHSv5zm2UIzWVUBxWPIN3jkfr
X-Google-Smtp-Source: AGHT+IHDNYvfMRv8zyHH1JNeWs0ql68SHRULGDlGv1iLXP5qckrtVzLARd4V2CyDi5rVA1F1+UAH8Q==
X-Received: by 2002:a17:90a:ae02:b0:2da:5aa5:5d5b with SMTP id 98e67ed59e1d1-2dd7f3e9db0mr3637843a91.3.1726968087781; Sat, 21 Sep 2024 18:21:27 -0700 (PDT)
Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com. [209.85.210.171]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2dd6ef978besm6713549a91.57.2024.09.21.18.21.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Sep 2024 18:21:27 -0700 (PDT)
Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-718ebb01fd2so623711b3a.2; Sat, 21 Sep 2024 18:21:27 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCUbA6sL7EcSxr5iw0m+IO7Xkk0h1spQi0S/FXJwM8BYmrUY4JAA86CeUYAJYYuZPTyQHWxJNpt6r+6yR1jtQV5r22dx+91rYHOGRdH288nmNvpVPYhMs1Xc7Evq5A==@ietf.org, AJvYcCWSgZ8JcYzPiIQR7xzxpwm5i3GCBYxaCT9DyBBG3v5OXA1aMkwKecLFblDy2AczXmcTno7FFhO7Tw==@ietf.org, AJvYcCWqfaxYd6MeIZ6rLa0F6Nb3tdf2bE2m1/tx3dAs9yrfsxCwMpDufFCEG8oERERfcfru1yWRiZ6k@ietf.org
X-Received: by 2002:a05:6a00:2d22:b0:70b:705f:8c5d with SMTP id d2e1a72fcca58-7199c9f4f2dmr4642597b3a.4.1726968087385; Sat, 21 Sep 2024 18:21:27 -0700 (PDT)
MIME-Version: 1.0
References: <EAA84133-F9D5-4380-994D-297993F13675@insa-lyon.fr> <01000191dc9a8080-119f64d0-f1d7-4549-9789-ba05daa87609-000000@email.amazonses.com> <CABCOCHRYQmo+XDZMGuTwNJ+OW2F1ZbRDcjMst40Z0GXpFD86-w@mail.gmail.com> <01000191dcc4509d-0c99ab29-a02e-4a3e-b68b-3b1d58a87f27-000000@email.amazonses.com> <CABCOCHT6Wsh=mwpPNq+3nGzf8EU8fGtwvstakEtbPetTsL9NDQ@mail.gmail.com> <01000191dd5fee26-d7465934-4131-40b1-9549-ff693917b0d6-000000@email.amazonses.com> <D0230B09-8D6B-4615-8C16-ED6BA6AAFDA7@insa-lyon.fr> <01000191fd1bd27b-042e2602-c072-44bf-9342-f38a74086dbb-000000@email.amazonses.com> <CABCOCHRw4Puhm2bNzSbXLsZD1-M+Miw6KypEbk=ENDj+C6xqPg@mail.gmail.com> <0100019202afbee4-44734060-0753-4ea1-b160-11772eda550a-000000@email.amazonses.com> <3dde2b41370c473389221aca2a371c8b@swisscom.com> <010001920ff499e8-e481c2ac-3e6d-4890-a990-f21f7a5d1599-000000@email.amazonses.com> <CABCOCHRGFE4a9PASHXHDxb6E=E59M6-Afp0V8ans9UNS+xxX3A@mail.gmail.com> <01000192103195f3-f453294b-3fad-4ad6-ad4c-365c4f6af7e1-000000@email.amazonses.com> <CABCOCHRvmZqcSOhquMJyqmrsPDRW-yf0M6a=KeoW9od9zUYr6g@mail.gmail.com>
In-Reply-To: <CABCOCHRvmZqcSOhquMJyqmrsPDRW-yf0M6a=KeoW9od9zUYr6g@mail.gmail.com>
From: Per Andersson <per.ietf@ionio.se>
Date: Sun, 22 Sep 2024 01:21:16 +0000
X-Gmail-Original-Message-ID: <CACvbXWHRL6dQkAb+17N7RCswCQGHn0Yg0YB9U-SUZ5hHSZKmjg@mail.gmail.com>
Message-ID: <CACvbXWHRL6dQkAb+17N7RCswCQGHn0Yg0YB9U-SUZ5hHSZKmjg@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: HQ4TS5AM7I5Q7I3DTDCS2DKTQUS52XR7
X-Message-ID-Hash: HQ4TS5AM7I5Q7I3DTDCS2DKTQUS52XR7
X-MailFrom: perkietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Kent Watsen <kent+ietf@watsen.net>, Thomas.Graf@swisscom.com, "netconf@ietf.org" <netconf@ietf.org>, draft-ietf-netconf-udp-client-server.authors@ietf.org, "netmod@ietf.org" <netmod@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: [netconf] Re: Re: Default statements on udp-client-server groupings
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/R8E7_N48tSI9oufjqhfe_sQvh5Q>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

Hi!

I might have missed significant parts of the discussion,
if so please correct me.


On Fri, Sep 20, 2024 at 4:19 PM Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Fri, Sep 20, 2024 at 9:08 AM Kent Watsen <kent+ietf@watsen.net> wrote:
>>
>>
>> Let me clarify, I’m trying to close the "default 0” statement on the "local-port” leafs issue.  Whether rfc8407bis is updated is a secondary concern.
>>
>> Andy (and others), do you believe this (to never set “default” or “mandatory”) to be a best-practice for reusable groupings?  Or more specifically and better for me, do you think the  "default 0” statement on the "local-port” leafs is okay or should be removed (in the tcl-client-server draft)?
>>
>
> In this case, default 0 meant use whatever port you want.
> IMO that is a bad practice and should never be done.

A client normally does this, and this is explained in the
text for ietf-tcp-client.yang:

    leaf local-port {
      if-feature "local-binding-supported";
      type inet:port-number;
      default "0";
      description
        "The local IP port number to bind to for when connecting
         to the remote peer.  The port number '0', which is the
         default value, indicates that any available local port
         number may be used.";
    }

I think this is fine.

For remote-port in tcp-client it should be removed IMHO. There
is no reason to mandate every TCP client to set a default value
for the remote port.


> In this case, the default is for an application well-known port assignment, so the
> groupings for the application should set the default port.

For server, I lean towards agreeing with Andy here.

If the default "0" is not refined by when the grouping is used,
a server might by mistake listen to a random port. I don't
know if this would be an issue in practice though, one would
hope that this minimal smoke test is performed before
releasing a YANG module that uses the grouping.


--
Per