IETF Logo Mail Archive

[dtn] Re: draft-ietf-dtn-bpv7-admin-iana

"Sipos, Brian J." <Brian.Sipos@jhuapl.edu> Tue, 01 October 2024 15:40 UTC

Return-Path: <Brian.Sipos@jhuapl.edu>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DBAC14F5F2 for <dtn@ietfa.amsl.com>; Tue, 1 Oct 2024 08:40:40 -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_ZEN_BLOCKED_OPENDNS=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=jhuapl.edu
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 ivCB1FrFHr_H for <dtn@ietfa.amsl.com>; Tue, 1 Oct 2024 08:40:36 -0700 (PDT)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) by ietfa.amsl.com (Postfix) with ESMTP id 464B9C1840CA for <dtn@ietf.org>; Tue, 1 Oct 2024 08:40:20 -0700 (PDT)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.18.1.2/8.18.1.2) with ESMTP id 491DIZ8v027248; Tue, 1 Oct 2024 11:40:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=JHUAPLDec2018; bh=CybnMEzGsbanuoIh8yNeiRvoeELS5l/sdf9CQQJph/w=; b=eSAQ02bpflf35/2GmsuC2awvzNWci9hA3sgggkJY1pr4XV8AqoH41h9hCADlfWE/fxmJ vfe7oC0u8/rAKDHTlgi5iIsxPNoh/4BZlZ8PzAT+58QWN4/KQ0iizJOkHmMbQUqAU9Dy hUHAbGPAUREWEBokExS+Rqr+ltKhhMm6Ofv+9UtrjMRXEmfjcGS3D0GdRvCMbzJsywk9 j/K1VWAy0I/utChSRy2F5qEXRErkmMwW5aJNb5c8Qd+ewFXPyF8TCmBdSdqz3uo09u6R +mKfpdbcrho1a83gO30jSvn9gmtouU/6+1UjTGkEMo0Cnv7x55riJ0ByloINbSCH0b/x zg==
Received: from aplex23.dom1.jhuapl.edu (aplex23.dom1.jhuapl.edu [10.114.162.8]) by aplegw01.jhuapl.edu (PPS) with ESMTPS id 41xau9kbn0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Oct 2024 11:40:19 -0400
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX23.dom1.jhuapl.edu (10.114.162.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 1 Oct 2024 11:40:18 -0400
Received: from APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2]) by APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2%5]) with mapi id 15.02.1544.011; Tue, 1 Oct 2024 11:40:18 -0400
From: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
To: Rick Taylor <rick@tropicalstormsoftware.com>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: draft-ietf-dtn-bpv7-admin-iana
Thread-Index: AdsT4GkHkiuKO3t5RiuZxqul0kKPnQALf85A
Date: Tue, 01 Oct 2024 15:40:18 +0000
Message-ID: <9b8d12c537df4e0fb45bc7252f4c0cab@jhuapl.edu>
References: <38A5475DE83986499AEACD2CFAFC3F98029AD337CC@tss-server1.home.tropicalstormsoftware.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98029AD337CC@tss-server1.home.tropicalstormsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.18]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0056_01DB13F6.AF6906E0"
MIME-Version: 1.0
X-CrossPremisesHeadersFilteredBySendConnector: APLEX23.dom1.jhuapl.edu
X-OrganizationHeadersPreserved: APLEX23.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-01_12,2024-09-30_01,2024-09-30_01
Message-ID-Hash: 7ECCSQRRDHKSQIXZR57O6ZLBXQMPGE24
X-Message-ID-Hash: 7ECCSQRRDHKSQIXZR57O6ZLBXQMPGE24
X-MailFrom: Brian.Sipos@jhuapl.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dtn.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: [dtn] Re: draft-ietf-dtn-bpv7-admin-iana
List-Id: "Delay Tolerant Networking (DTN) discussion list at the IETF." <dtn.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/NbOsQAWw3MyXbcTAHeKeXAnVyzo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Owner: <mailto:dtn-owner@ietf.org>
List-Post: <mailto:dtn@ietf.org>
List-Subscribe: <mailto:dtn-join@ietf.org>
List-Unsubscribe: <mailto:dtn-leave@ietf.org>

Rick, I actually think no that should not be the case for payload block
BTSD, a.k.a. the ADU. This may be an under-/un-specified area of BPv7 but
any processing of the ADU by an application will happen after delivery and
so after the point at which the BPA can receive feedback on the validity of
that payload block BTSD. Perhaps this merits an errata note specifically
about the payload block and its relationship to the ADU: as long as the
payload block type specific data is in fact a byte string it is considered
valid by the BPA for block processing purposes.

 

This is my interpretation of the current spec, does it agree with as-written
BPA requirements?

 

From: Rick Taylor <rick@tropicalstormsoftware.com> 
Sent: Tuesday, October 1, 2024 5:05 AM
To: dtn@ietf.org; Sipos, Brian J. <Brian.Sipos@jhuapl.edu>
Subject: [EXT] draft-ietf-dtn-bpv7-admin-iana

 


APL external email warning: Verify sender rick@tropicalstormsoftware.com
<mailto:rick@tropicalstormsoftware.com>  before clicking links or
attachments

 

Hi Brian,

 

I'm just re-reading draft-ietf-dtn-bpv7-admin-iana, and I have one question
regarding paragraph 4 of Section 2:

 

>  If an administrative element receives a not-well-formed ADU or an

   administrative record type code which is not able to be processed by

   the element, the record SHALL be ignored by the element.  The

   processing of a received administrative record ADU does not affect

   the fact that the bundle itself was delivered to the administrative

   element or any related BPA processing of (e.g. status reports on) the

   enveloping bundle.

 

Would it not make more sense to state something like:

 

"If an administrative element receives a not-well-formed ADU or an

   administrative record type code which is not able to be processed by

   the element, the record MUST be processed according to the rules for
Block Processing Control Flags defined in Section 4.2.4 of RFC9171"

 

This would re-use the mechanisms in RFC9171 consistently, as the Payload
Block is a regular block (in most cases) and has a perfectly useable Flags
field?

 

Late comment I know.

 

Rick

v2.29.0 | Report a Bug | By Email | System Status