IETF Logo Mail Archive

Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis

Andy Bierman <andy@yumaworks.com> Tue, 12 March 2024 16:01 UTC

Return-Path: <andy@yumaworks.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 BB80BC14F61E for <netmod@ietfa.amsl.com>; Tue, 12 Mar 2024 09:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_BLOCKED=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, URIBL_BLOCKED=0.001, 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 Ij7XxAB3-sy1 for <netmod@ietfa.amsl.com>; Tue, 12 Mar 2024 09:01:41 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9930C14F5E4 for <netmod@ietf.org>; Tue, 12 Mar 2024 09:01:41 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1dd922cbcc7so19251965ad.2 for <netmod@ietf.org>; Tue, 12 Mar 2024 09:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1710259301; x=1710864101; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r2l/9cKg3k7dhVjQ7B1GgrRsjmtdqtIRR1uFjQeonCw=; b=T4u83wrSjZ+GJjFpc1F0+gyYIIp0K1MDLaUpXQR/mFJGW+MGlxJxLAfSHgT6yU/mmB OGup4y5rtqah1r4sJuVIygOe0eRZ4iCqBw2CGwNLCtXNz/C4oZOqhyDP8a7BhoK6ZGIB Jc/N0QXkIILPD8rBWSBJM4OBy0HlN0UMcxECFWDXg/CNsPq9Sr5sWT/YjwrkjDpQiHGq ZM2FBpVDWzSyW4Vd3WfrGEcSvi5tmJ0QEg6lSaG3DsMgg0feNby5hZZxqRw52XnLGAao eztGaretOU8LmelguBjyKknhR8elEyME0V8faUKbASq2zWbFxlg0MQK1r26geforl14w F3yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710259301; x=1710864101; h=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=r2l/9cKg3k7dhVjQ7B1GgrRsjmtdqtIRR1uFjQeonCw=; b=n41k92KJQNSEoLhfv8EBG9ERvwUJAJ662druT+rKfRKJ6j7SAL70UChr875BZHQD1P gTbIdjUWgS4NxPesN27AxuSlFJtVKsiJV+BDRVLFjwHoGt3AjiUAK39vux6gzWGQSYfJ G3Q/kYhEiCQ7N0tKZaNv3k9a80fb1kbnPV70FBAiiqgH46uhOMSfKB71Ze/kNWjGCZpL bgspTzIu004st6nYSdoFYhHfjOXBHgWy5JRoGdqw3FRITGx9zt9UTYqhP/19e6qLyY9z A4HOim4bpeaGMZyAiNh9IGtemZyaagEI/Hn8Q5x2r1LgVb1KzLgBDgSEcYd6sigTMWi5 6S4Q==
X-Forwarded-Encrypted: i=1; AJvYcCUKrmjC2+WwWXTOSvZCCjRSGDvk1qo8ohttB5l78zJ7y4Zwp44m0tTF8Ds0UmrgCFePEHYlrMDIRJqnAvuErfg=
X-Gm-Message-State: AOJu0YxkK3+/tqDDvF4DB2q6jum2wy0ww+JBmsaatPy5wlO8KxhuXLEF hjGuqbiI/yMO3goOl5lj/fBeKqs0FRIRvYqseDnUlzAE434C81qdM9wtSSCx9W2cVzH08ITZ0a0 ewcYTgwkqg3uMEKszLcn3qbJvG/EaM2y1J/2mMA==
X-Google-Smtp-Source: AGHT+IF+m34Uhmia3V0iPWJT44kpRMxS5Eeus2qWjPyWnF8IeRXOQKhHvmkLVnuBBCXcImu/2NCn0pesE5uSigTFKSk=
X-Received: by 2002:a17:90a:c684:b0:29b:277d:2590 with SMTP id n4-20020a17090ac68400b0029b277d2590mr9963733pjt.34.1710259301078; Tue, 12 Mar 2024 09:01:41 -0700 (PDT)
MIME-Version: 1.0
References: <170911084467.36197.13909323798182085568@ietfa.amsl.com> <DU2PR02MB10160D87F56348C8C6C3D947188582@DU2PR02MB10160.eurprd02.prod.outlook.com> <0E99F975-162C-4703-93F7-B9EE82D4186B@tail-f.com> <DU2PR02MB101606A8503CD26291F18034D88232@DU2PR02MB10160.eurprd02.prod.outlook.com> <314d5e9c-3a98-4dd2-ad05-b426cd376644@alumni.stanford.edu> <8fbc84a6-cfd4-4d2d-9118-09bbb25bbc4c@constructor.university> <DU2PR02MB10160F66C4D98D859480B81AB88222@DU2PR02MB10160.eurprd02.prod.outlook.com> <5b2d4e07-6ecb-48b2-9952-209f8e392a09@constructor.university> <6C683BE5-5009-46AA-B178-CEA33C761789@tail-f.com> <CABCOCHS0tyiiFjbieBiLhW_T+R4boaJ7oWfg4M-zzzf8cQYAeQ@mail.gmail.com> <DM6PR11MB47089E60A0DB36C8459EC302DB2B2@DM6PR11MB4708.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB47089E60A0DB36C8459EC302DB2B2@DM6PR11MB4708.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 12 Mar 2024 09:01:29 -0700
Message-ID: <CABCOCHQ0X44L+wq=R3hT7ggAnuLBvaizKfEDZ2ij2gxvKj51Sw@mail.gmail.com>
To: "Per Andersson (perander)" <perander@cisco.com>
Cc: Jan Lindblad <janl@tail-f.com>, Jürgen Schönwälder <jschoenwaelder@constructor.university>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d762a061378c66c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7E2sKdlk478Qe6NqeUm7R7tN_5E>
Subject: Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2024 16:01:45 -0000

On Tue, Mar 12, 2024 at 7:28 AM Per Andersson (perander) <perander@cisco.com>
wrote:

> Andy Bierman <andy@yumaworks.com> on Tuesday, March 12, 2024 15:14:
> > On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad <janl@tail-f.com<mailto:
> janl@tail-f.com>> wrote:
> >> Then we have the other thing with RESTCONF where the module names are
> used instead, which also causes some (unnecessary) confusion. If NETCONF
> and RESTCONF could use the same "prefixes", things would be easier. In the
> early days of programming (I mean in the 60's), FORTRAN programmers were
> told to choose short function and variable names. This mindset has long
> since been abandoned. Why is this still a good practice in YANG prefixes?
> >
> > I disagree with any changes to module prefixes.
> > They are not confusing to anybody who bothers to learn a little about
> YANG.
> > Long prefixes make YANG harder to read, not easier.
>
> I disagree with this (hence agree with Jan).
>
> It was confusing to learn that RESTCONF and NETCONF
> use different prefixes.
>
> Short prefixes are nice when writing, longer descriptive prefixes
> are better when reading. Why would otherwise other identifiers
> have these long form names, and not have short identifiers too?
>
>

Module names need to be longer so they are unlikely to clash.
All other identifiers are scoped within a namespace, so no technical reason
to be longer.
I agree that using prefixes that are already assigned should be avoided.



>
> --
> Per


Andy

v2.23.0 | Report a Bug | By Email