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

Andy Bierman <andy@yumaworks.com> Sat, 21 September 2024 16:11 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF3C14F61D for <netconf@ietfa.amsl.com>; Sat, 21 Sep 2024 09:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
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 q6iuhLxNnhff for <netconf@ietfa.amsl.com>; Sat, 21 Sep 2024 09:11:31 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 7351EC14F5E3 for <netconf@ietf.org>; Sat, 21 Sep 2024 09:11:31 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2db6b13c6a0so555659a91.1 for <netconf@ietf.org>; Sat, 21 Sep 2024 09:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1726935091; x=1727539891; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=cpiARnkIfTvoFlkL1h5pKqZrKaA9PkRKs5anfijEMDM=; b=Ah9vj667r8XjhU1GBhVfrixmQ1ur1ymeJfkKpSAhDmL6DgzZ92v1JqbqcaTou1Q5qN SvQQDMZwYnnQFfmF8SnvZ9kseg/sQWwkxTUsBmPHzZmTyMCDPbNXABZE5SpwuiAy3Rpv AH0jphFS7ER150LeyRjy+gfkhtumNryLOenCHtc31iFt5U7ne3rOByKRuHIUPWM2GpsB 4MmBiASEqlwksKGFm1ZNb2+AXdL4aN1UI++VdqOGaCACCyFHIHOV0rdKV4OAcmnfjDjh LxWm+kTB+V5qG3hqtmV2Z4UO58ONWqQapDZhAIIU4av8vwnkl43R1b/Rgiu8ms/O/5wj 6W+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726935091; x=1727539891; h=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=cpiARnkIfTvoFlkL1h5pKqZrKaA9PkRKs5anfijEMDM=; b=NKPHEwEhm20huHPvcVlF+KfunWbMG2/HJqtcdAciM8i99xlMFt5RTjefKlpdfrdCnb KnPT70QAcA/VvYYm9elU3tHIh5gH0FTw3qjO63lufIswfhF0zVZeR6G5pWFZ4l/MZRre 1rOdHbq+2402eMjx/CVRxw/NZWvHRyrshku8QSehRQY4OFguh+op3+pm4Y4Py6E8l1AE y236PEUnCq5i6TRdXeam1jTmXsEtvKVQISKWKZyd+2jkbDn2s5Ecsy6kTVwAUxzt7+Xg E1OMCGU2Qrs8sujeSRhV8EFmbAEDsycMg/noHW4axXreAGyCJE4u6tWK+xnTXnCmN7JK OFdw==
X-Forwarded-Encrypted: i=1; AJvYcCX89kLn3e3pXFsZAQ9a9odvvSZG+byYrH9mBgpZgirAjAScTAEf6Anos6USCkST6ILhb/CTDlqp@ietf.org
X-Gm-Message-State: AOJu0YwCGkk8vEj4w0hoVKOE+6IUdFDHGHJyfxH3UqpbOSAgBNqGLv32 wvvBnPgfACFoe796JhsARKQN6xRKlvyKoW7wyMsQd3YaGbxfWKfbrpfdF8MlDtZDumz33/i5Y/7 4tnYjQy2D/5VsULq4l8leEXZ8YbvFkYKgTgtnkIkq5q/Zh0J/vs1iPA==
X-Google-Smtp-Source: AGHT+IENVpoYrdmVeA7A/iWVeoqJC6uoB66VifJed0dEMNqnuPx4wJu8BS262PTLdV7LaOVr3uNUplUZJTlH2q1yXYs=
X-Received: by 2002:a17:90a:514e:b0:2d8:b96c:3c65 with SMTP id 98e67ed59e1d1-2dd7f187091mr3457840a91.0.1726935090761; Sat, 21 Sep 2024 09:11:30 -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> <CACvbXWFchBh2Mvzvmuwt5nMu3gwUzw3LpP249U6LzfmkP6BkEQ@mail.gmail.com>
In-Reply-To: <CACvbXWFchBh2Mvzvmuwt5nMu3gwUzw3LpP249U6LzfmkP6BkEQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sat, 21 Sep 2024 09:11:19 -0700
Message-ID: <CABCOCHQkyhFS-RBo7raMXLFqSEbENzbthDecBO1pQ_98tavXdw@mail.gmail.com>
To: Per Andersson <per.ietf@ionio.se>, Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a2b42d0622a368dd"
Message-ID-Hash: FHBOWZTCX6PNEP3NKZO5PWNQC76P6WFF
X-Message-ID-Hash: FHBOWZTCX6PNEP3NKZO5PWNQC76P6WFF
X-MailFrom: andy@yumaworks.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netconf] Re: [netmod] Re: Default statements on udp-client-server groupings
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/rjJQSN5L_qn18v6vPy-0vwTmkQc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>

On Sat, Sep 21, 2024 at 5:54 AM Per Andersson <per.ietf@ionio.se> wrote:

> Hi!
>
> I might have missed significant parts of the discussion,
> if so please correct me.
>
>
>
I think you meant to CC the WG



> 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.
>
>
I was making a more generic statement about layering groupings.
Even though the port number is a transport layer setting, it is an
application-layer decision.



>
> > In this case, the default is for an application well-known port
> assignment, so the
> > groupings for the application should set the default port.
>
> 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.
>
>
IMO it is better for the lower layer grouping to say nothing, rather than
assume
this behavior for special value 0, and force the uses-stmt to change it.



>
> --
> Per
>

Andy