[Tvr] Roman Danyliw's Discuss on draft-ietf-tvr-requirements-08: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 14 April 2026 15:08 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tvr@ietf.org
Delivered-To: tvr@mail2.ietf.org
Received: from [10.244.6.151] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 62591DC06D41; Tue, 14 Apr 2026 08:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776179305; bh=xUoZNmt9HpJQsF84AKYtLqhnE3LBwW6K5Xzy49bjlTc=; h=From:To:Cc:Subject:Reply-To:Date; b=m3JqeDeIeLkjAwLwQTMWrmjezKnaqsnAncuRMiDig+SK8Zc+paUcrG3AmVP6fSdnU M/+bI+78ifxb+pDCghNRbiryyYcBFywrH9xgMxn9k0r8Tvp6jGj4/kfdDGyQkxiH/r xeG+w+RBS2JXLMSN1OhuUyHXz4MpWncAN7Qx8xYY=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.61.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <177617930531.805737.3313278622669200575@dt-datatracker-647897bf7-7f2k5>
Date: Tue, 14 Apr 2026 08:08:25 -0700
Message-ID-Hash: G5WZGVITIEIVFSMUMQIUEQEA6T3D2MFS
X-Message-ID-Hash: G5WZGVITIEIVFSMUMQIUEQEA6T3D2MFS
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-tvr-requirements@ietf.org, edward.birrane@jhuapl.edu, tvr-chairs@ietf.org, tvr@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Roman Danyliw <rdd@cert.org>
Subject: [Tvr] Roman Danyliw's Discuss on draft-ietf-tvr-requirements-08: (with DISCUSS and COMMENT)
List-Id: Time-Variant Routing <tvr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tvr/LDsC8_TKMFN-94nUmz-YYMmDqp4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tvr>
List-Help: <mailto:tvr-request@ietf.org?subject=help>
List-Owner: <mailto:tvr-owner@ietf.org>
List-Post: <mailto:tvr@ietf.org>
List-Subscribe: <mailto:tvr-join@ietf.org>
List-Unsubscribe: <mailto:tvr-leave@ietf.org>

Roman Danyliw has entered the following ballot position for
draft-ietf-tvr-requirements-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.2.
4.2.  Support Proxy Advertisement

   Proxies can help to improve the efficiency of the network.  There are
   some entities in the network that do not have routing functions.
   When their properties change, they are unable to notify other
   entities in the network.  Proxy nodes can help nodes without routing
   functions to advertise information, thus improving the efficiency of
   the network.  Therefore,

   Systems must support proxy entities to help non-routing nodes
   implement information advertisement.

-- What is a proxy in this context?
-- What does it mean to “support proxy entities”?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support the positions of Éric Vyncke and Gorry Fairhurst on clarifying text
around the requirements.

** Are the requirements in Section 4, as the name would imply, a “Requirements
Summary”, of those in Section 3?  There are various clauses in Section 3 which
talk about “should” which don’t appear to me to cleanly align with the Section
4 text.

** Section 4.5

4.5.  Support Appropriate Time Accuracy
   The accuracy of the time cannot be too large or too small; otherwise,
   convergence may not be possible.  Therefore,

   Systems must support appropriate time tolerance.

With no definition or framing of “appropriate”, isn’t any time tolerance
acceptable?  It isn’t clear how this text establishes a requirement.