[NSIS] IESG Review of draft-ietf-nsis-req-08.txt - Comments 1

Allison Mankin <mankin@psg.com> Fri, 27 June 2003 04:35 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04770 for <nsis-archive@odin.ietf.org>; Fri, 27 Jun 2003 00:35:07 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R4Yf416181 for nsis-archive@odin.ietf.org; Fri, 27 Jun 2003 00:34:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vkvw-00040q-J0; Fri, 27 Jun 2003 00:34:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vku3-0003s5-4z for nsis@optimus.ietf.org; Fri, 27 Jun 2003 00:33:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04691 for <nsis@ietf.org>; Fri, 27 Jun 2003 00:31:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vku0-000178-00 for nsis@ietf.org; Fri, 27 Jun 2003 00:32:00 -0400
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Vktp-000170-00 for nsis@ietf.org; Fri, 27 Jun 2003 00:31:50 -0400
Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19Vktk-000Obw-9I; Fri, 27 Jun 2003 04:31:44 +0000
To: brunner@ccrle.nec.de
Cc: john.loughney@nokia.com, nsis@ietf.org, harald@alvestrand.no
Reply-To: mankin@psg.com
Date: Thu, 26 Jun 2003 21:31:44 -0700
From: Allison Mankin <mankin@psg.com>
Message-Id: <E19Vktk-000Obw-9I@psg.com>
Subject: [NSIS] IESG Review of draft-ietf-nsis-req-08.txt - Comments 1
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>

The IESG reviewed the NSIS Requirements.  There was some concern over
the readability.  In addition, there were a few technical comments that
should be addressed.  Here are Harald Alvestrand's.

Allison

------- Forwarded Message


Date: Thu, 26 Jun 2003 08:35:22 -0700
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: iesg@ietf.org
Subject: A couple of comments on draft-ietf-nsis-req


This section, from the start of section 5, worries me:


   The parts of the networks we differentiate are the host-to-first
   router, the access network, and the core network. The host to first
   router part includes all the layer 2 technologies to access to the
   Internet. This part of the division is especially informal and may
   incorporate several access segments. In many cases, there is an
   application and/or user running on the host initiating signaling.
   The access network can be characterized by low capacity links,
   medium speed IP processing capabilities, and it might consist of a
   complete layer 2 network as well. The core network characteristics
   include high-speed forwarding capacities and inter-domain issues.
   These divisions between network types are not strict and do not
   appear in all networks, but where they do exist they may influence
   signaling requirements and will be highlighted as necessary.

First of all, the grammar is sufficiently convoluted that I have problems 
parsing it.

Second, I have definitional problems.

I have problems imagining how an access network can work if it does NOT 
contain a "complete layer 2 network" - after all, a link is, in its way, a 
layer 2 network. OTOH, I don't think GSM/GPRS can fairly be called a "layer 
2 network" - it's more complex than that - but it's definitely being used 
as an access network.

The sentence "host to first router part includes all the layer 2 
technologies to access to the Internet" does not parse, and makes the 
definition only make sense when the first router is connected to the 
Internet - I don't think that was intended.

Since this paragraph is key to the overall architectural constraints, I 
think it's rather important to make it crystal clear.

Section 5.5.1 on scalability worries me a lot, because it uses "scalable" 
without referring to a scale; while it may be appropriate to "scale" an 
end-system-to-first-router protocol to 10.000 users and say "good enough", 
I think core routers have scalability requirements to millions of active 
participants (which argues for them not having to see their state....)

I would like to see some hand-wringing here like:

"The NSIS protocols MUST be scalable up to the level of ubiquity - that is, 
if every end-user on the network uses NSIS functions, the system MUST NOT 
be brought to a catastrophic failure, but continue to give service 
appropriate to the resources available."

There might be more than this, but this is at least worrying.....





------- End of Forwarded Message


_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis