NSIS Issues
Last Updated: January 23, 2003
To submit a new issue, send an e-mail to
the NSIS WG Mailing List, using the following template:
Issue Name:
Submitter
name: Your_Name_Here
Submitter
email address: Your_Email_Address_Here
Date
first submitted: Insert_Date_Here
Reference:
URL to e-mail describing problem, if available
Document:
Document Requiring change
Comment
type: ['T'echnical | 'E'ditorial]
Priority:
['S' Must fix | '1' Should fix | '2' May fix ]
Document
Section: Insert_Section_Number_Here
Rationale/Explanation
of issue:
Requested
Change:
For open issues, the following
values are used in the Status Field:
Text
Proposed - Text
has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed,
consensus has been reached, but the fix hasn't been included in a specification
yet.
Pending - Discussion is on-going, no
proposed text has been proposed
No
Discussion - No
discussion has been initiated on this issue.
Clarifying
Text Required -
The issue can be closed if additional clarifying text is added to the draft
Possible
Reject - Issue
will be rejected unless objections occur.
Document: draft-ietf-nsis-req-xx.txt
|
Issue Number |
Status |
Title |
Owner |
|
1 |
Text Proposed |
Reuse of
provisioning protocols clarification |
Georgios.Karagiannis@eln.ericsson.se |
|
2 |
Text Proposed |
Definition of
Receiver-initiated signaling protocol seems flawed |
anders.p.bergsten@telia.se |
|
3 |
No Text |
Section 5.2.2 contains
two different and possibly opposing requirement |
anders.p.bergsten@telia.se |
|
4 |
Text Provided |
Section 5.3.4 needs
clarification |
anders.p.bergsten@telia.se |
|
5 |
Pending |
Network MUST NOT
know that a relationship between the group flows exists is impractical
requirement |
anders.p.bergsten@telia.se |
|
6 |
No Text |
MUST/ SHOULD
clarification |
anders.p.bergsten@telia.se |
|
7 |
Text Provided |
Need clarification on UMTS
Access session |
nhamer@nortelnetworks.com |
|
8 |
Text Provided |
Definition of RMF
should also mention about de-allocation |
kuntal@iqmail.net |
|
9 |
Text Provided |
The current
definition of Provisioning has unnecessary text |
kuntal@iqmail.net |
|
10 |
Text Provided |
QoS technology definition needs correction |
kuntal@iqmail.net |
|
11 |
Text Provided |
Need clarification
on uses of NSIS signaling |
kuntal@iqmail.net |
|
12 |
Text Provided |
Clarification on
requirement to use normal L3 routing |
kuntal@iqmail.net |
|
13 |
Text Provided |
clarification on
text for section 5.2.1 |
kuntal@iqmail.net |
|
14 |
Text Provided |
Rephrase 5.2.2 |
kuntal@iqmail.net |
|
15 |
Text Provided |
editorial
nits |
cedric.aoun@nortelnetworks.com |
|
16 |
Text Provided |
Simplify
text on Control Information |
cedric.aoun@nortelnetworks.com |
|
17 |
Text Provided |
Text
simplification |
cedric.aoun@nortelnetworks.com |
|
18 |
Text Provided |
NSIS
Responder clarification |
cedric.aoun@nortelnetworks.com |
|
19 |
Text Provided |
Protection
of Non-signaling message clarification |
cedric.aoun@nortelnetworks.com |
|
20 |
Text Provided |
5.1.1
clarification |
cedric.aoun@nortelnetworks.com |
|
21 |
Text Provided |
5.3.3
clarification |
cedric.aoun@nortelnetworks.com |
|
22 |
Text Provided |
Rewording
suggestions |
cedric.aoun@nortelnetworks.com |
|
23 |
Text Provided |
Flow
Bundling support |
cedric.aoun@nortelnetworks.com |
|
24 |
Text Provided |
Modify
text for application independence |
Vlora.Rexhepi@eln.ericsson.se |
|
25 |
No Discussion |
Missing
Framework references |
Vlora.Rexhepi@eln.ericsson.se |
Issue Number: 1
Issue Name: Reuse of
provisioning protocols clarification
Submitter name: Georgios
Karagiannis
Submitter email
address: Georgios.Karagiannis@eln.ericsson.se
Date first submitted:
January 2003
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority: 2
Document Section: 5.1.5
Requested change:
Change:
5.1.5 NSIS MUST reuse existing provisioning
Reuse existing functions and protocols for
provisioning within a
domain/subdomain unchanged. (Motivation:
'Don't re-invent the
wheel'.)
to:
5.1.5 NSIS MUST be able to reuse existing
provisioning
Reuse, where possible, existing functions
and protocols for provisioning
within a domain/subdomain unchanged.
(Motivation: 'Don't re-invent the
wheel'.)
Issue Number: 2
Issue Name: Definition
of Receiver-initiated signaling protocol seems flawed
Submitter name:
Anders Bergsten
Submitter email
address: anders.p.bergsten@telia.se
Date first submitted:
03-01-20
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority: 2
Document Section: 2,
pg 3, last paragraph
Rationale/Explanation
of issue: Definition of Receiver-initiated signaling protocol seems flawed. The
definition states that the NSIS responder _initiates_ the reservation on behalf
of the receiver. According to the definition of NSIS Responder, the NSIS Responder
_responds_ to NSIS messages. The NSIS Responder does not initiate a message;
hence, the definition is flawed. The definition of Receiver-initiated signaling
protocol should be defined by where the NSIS Initiator is situated, not where
the NSIS Responder is situated. Therefore I propose a change to something
similar to the below.
Requested change:
"Receiver-initiated
signaling protocol: A receiver-initiated signaling protocol is a protocol where
the resources that the signaling protocol should reserve is situated
topologically closer to the source than the NSIS Initiator is. This means is
that the resource management functions need to be processed from the NSIS
Initiator back towards the sender."
Issue Number 3
Issue Name: Section 5.2.2
contains two different and possibly opposing requirement
Submitter name:
Anders Bergsten
Submitter email
address: anders.p.bergsten@telia.se
Date first submitted:
03-01-20
Reference: -
Document: draft-ietf-nsis-req-06.txt
Comment type: T
Priority: 2 (?)
Document Section:
5.2.2
Rationale/Explanation
of issue: The section contains two different and possibly opposing requirement.
The title says "No constraint MUST be posed on the signaling..." and
page 12, paragraph 5 says "... NSIS signaling used between those virtual
routers MUST follow the same path as the data". These are two different
requirements where the second actually pose a constraint on the signaling path.
Requested change: I
personally prefer the second requirement and propose to use only that. This
requirement states that it is some constraint on the path followed, which I
think is good. I think it also sufficiently covers both the "bandwidth
broker" and on-path alternatives to signaling. If people still prefer the
first, I would like the requirement to state the following: "The only
constraint on the signaling and NSIS forwarders is that they follow the correct
AS-path" (or some equivalent term for AS-path).
Issue Number: 4
Issue Name: Section
5.3.4 needs clarification
Submitter name: Anders
Bergsten
Submitter email
address: anders.p.bergsten@telia.se
Date first submitted:
03-01-13
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority: 2
Document Section:
5.3.4
Rationale/Explanation
of issue: "A request for service MUST be answered at least with a yes or
no". This does not state who should send the reply, neither is it clear
enough on how to be interpreted. The only thing this adds to me is uncertainty
- there is a risk that someone interprets this as "if I have sent a
request I can expect a reply", ie "The network MUST answer a request
for service". This is impossible to promise, since packets can be lost.
Requested change: I
prefer to keep the requirement in the title and let that be the requirement.
This requirement is slightly different than what is written within the text,
and it talks about "success" of a service. If the requirement in the
text should be interpreted as "A NSIS responder MUST answer a request for
service", I want that stated. Thus, I request one of two resolutions to
this issue:
1) Use only the requirement in the
title (only a success needs to be reported) and remove the
"clarifying" requirement in the text.
2) Add information on WHO must answer
to the request (Something along, "The NSIS responder MUST reply with at
least a yes/no").
Issue Number: 5
Issue Name: Network
MUST NOT know that a relationship between the group flows exists is impractical
requirement
Submitter name:
Anders Bergsten
Submitter email
address: anders.p.bergsten@telia.se
Date first submitted:
03-01-20
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority: 2
Document Section:
5.4.5
Rationale/Explanation
of issue: The requirement ("the network MUST NOT know that a relationship
between the group flows exists", etc) in last paragraph of the section is
a very hard requirement to meet up with, I think. The interaction between
routing and state maintenance causes some problems here. I start with a pure
on-data-path signaling scenario. If a router is to maintain state and get a
group of state requests, it must assume that they actually belong to him,
otherwise it does not make sense. This requires either that the previous node
does group flows together that have a relation with next-hop node or that the
node can force relationship onto a group of flows (this method is used by
MPLS), where we control the path. If we do not allow for "the
network" to know relationships between flows, a node cannot assume that
the resource belongs to him and need to have a method to find the right owner
of the flow - which may be harder to solve than allowing a node to know a
relationship between flows.
Requested change: Not
sure how to resolve the issue, unfortunately. The best thing would be to remove
the paragraph and leave only the requirement on that NSIS MAY group flows.
Issue Number: 6
Issue Name: MUST/
SHOULD clarification
Submitter name:
Anders Bergsten
Submitter email
address: anders.p.bergsten@telia.se
Date first submitted:
03-01-20
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: E
Priority: 2
Document Section: document
Then I have a general
comment about the use of MUST/SHOULD... I feel there are too many requirements
that are MUSTs, and I am not sure that it is understood how these requirements
is met up by a protocol (ie what is the cost for having to implement this). For
example, what is the implication of this requirement "State MUST be
addressed independent of flow identification"? I would request that the
MUSTs/SHOULDs etc is not to be interpreted as in RFC2119 as I believe that
would be hard to find a protocol that match all the MUSTs. I would request to
use must/should/may instead so that subsequent work do not interpret them as
"hard" requirements, but rather as indications of requirement.
Issue
Number: 7
Issue Name: Need clarification on UMTS Access session
Submitter name: Louis-Nicolas Hamer
Submitter email address: nhamer@nortelnetworks.com
Date first submitted: 22/01/2003
Reference: none
Document: draft-ietf-nsis-req-06.txt
Comment type: T
Priority: 2
Section: 10.3
I
have a few comments on section 10.3 UMTS access.
Sorry for sending the late comments.
Section
10.3 provides a good description of the UMTS access overall
architecture for 3GPP release 5. But, it then speculates on how
NSIS
could fit into the 3GPP release 6, which is still not yet
defined by the way.
Although, I agree NSIS could indeed have a place in 3GPP release
6,
I can't agree with the way it is depicted in the draft
currently.
First,
I am not convinced the PCF is the right place to locate the NSIS
Initiator. Why not consider the GGSN? Or the UE?
Secondly, if it would be located in the PCF (or the GGSN for
that matter), what
would be the value-added? I personally think the important
section of the network
where nsis signaling would be needed is at the access level, not
in the backbone network.
So why originate NSIS after the access network? Value is limited
IMHO.
I
think having this example, as it is currently is not acceptable. I propose
we clean it up:
-maybe we can agree on a
more acceptable example usage of nsis in UMTS access?
-maybe we could instead
list all of the possible usages (instead of listing only one)
-or strip out the example
all together (I would prefer not too).
I am not sure who
contributed this section, so I guess in order to achieve closure, it would be
best
if the contributors contacted me directly or through the mailing
list. Unless the chair (or someone else) has a better way forward.
More comments:
There is a need to
capture the scope of signaling (NSIS) in all 3G
wireless networks
besides UMTS (e.g. need to cover cdma2000). Otherwise,
it gives a false
impression that, the NSIS requirements are UMTS
centric. I read the
sections 10.2 and 10.3. There is a good similarity
between 3GPP and
3GPP2 IP networks. The following is my attempt to
generalize the
Figure:
+--------+
+----------| P-CSCF
|-------> SIP signaling
/ +--------+
/ SIP :
: +--------+
+----------------+
: | Policy |
| NSIS Forwarder |
: +--------+
+----------------+
: :
|
: : COPS
|
: : |
+----+ +--------+
|
| UE |----------| Access
|------------+ +----+
+----+ | Gateway|----------------------| ER |
+--------+ +----+
I also agree with
Louis that UE and/or the Access Gateway are the most
natural candidates
for NSIS initiator. Therefore I changed the above
figure to reflect
that. There is also similarity between UMTS/GPRS and
cdma2000 radio link
QoS setup e.g. UMTS creates different radio bearers
with different QoS
needs and in cdma2000 the same is done with multiple
service instances. If
my suggestion is agreeable, then I will be happy
to provide updated
text for section 10.2 and 10.3.
Issue Number: 8
Issue Name: Definition
of RMF should also mention about de-allocation
Submitter name:
Kuntal Chowdhury
Submitter email
address: kuntal@iqmail.net
Date first submitted:
03-01-22
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: E
Priority: 2
Document Section: 2
Rationale/Explanation
of issue: Definition of RMF should also mention about de-allocation
Requested change:
Resource Management
Function (RMF): An abstract concept,representing the
management of
resources in a domain or a node. This includes admission
control and resource
allocation/de-allocation.
Issue Number: 9
Issue Name: The
current definition of Provisioning has unnecessary text
Submitter name:
Kuntal Chowdhury
Submitter email
address: kuntal@iqmail.net
Date first submitted:
03-01-22
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority:
Document Section: 2
Rationale/Explanation
of issue: The current definition of Provisioning
has unnecessary
texts. For example it says LSP initiation in MPLS is a
matter of
provisioning. IMO, it's not entirely correct, LSPs can be
initiated by a LER
based on it's internal logic which may be configured
by suitable
provisioning mechanism.
Requested change:
Provisioning: the act
of configuring an NE for allocating resources to a
flow or aggregate of
flows.
Issue Number: 10
Issue Name: QoS
technology definition needs correction
Submitter name:
Kuntal Chowdhury
Submitter email
address: kuntal@iqmail.net
Date first submitted:
03-01-22
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority:
Document Section: 2
Rationale/Explanation
of issue: QoS technology definition needs a bit of
correction, e.g. MPLS
is not really a QoS technology, it is more used
for Traffic
Engineering.
Requested change:
QoS Technology: a
generic term for a set of protocols, standards and
mechanisms that can
be used within a QoS domain/subdomain to manage the
QoS provided to flows
or aggregates that traverse the domain. An example
QoS technology is
DiffServ. A QoS technology is associated with certain
QoS provisioning
techniques.
Issue Number: 11
Issue Name: Need
clarification on uses of NSIS signaling
Submitter name:
Kuntal Chowdhury
Submitter email
address: kuntal@iqmail.net
Date first submitted:
03-01-22
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority:
Document Section: 2
Rationale/Explanation
of issue: The document states that NSIS is not
restricted to QoS
signaling only, it also covers signaling required for
other purposes such
as ....not mentioned!
The requirements are
based on the fact that a signal is initiated from
an NSIS initiator for
allocation of network resources. It would be nice
to see some examples
of non-QoS signals that require allocation of
network resources in
the internet.
Issue Number: 12
Issue Name: Clarification
on requirement to use normal L3 routing
Submitter name:
Kuntal Chowdhury
Submitter email
address: kuntal@iqmail.net
Date first submitted:
03-01-22
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: T
Priority:
Document Section: 4.1
Rationale/Explanation
of issue:
" 6. NSIS assumes to operate with networks
using standard ("normal")
L3 routing. Where "normal" is
not specified more exactly on purpose."
this is very vague
assumption. Not sure which routing scheme is
considered
"normal". If some are normal then which ones are
"abnormal"?
Requested change:
6. NSIS assumes to
operate with networks using standard L3 routing.
Issue Number: 13
Issue Name:
clarification on text for section 5.2.1
Submitter name:
Kuntal Chowdhury
Submitter email
address: kuntal@iqmail.net
Date first submitted:
03-01-22
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: E
Priority:
Document Section:
5.2.1
Rationale/Explanation
of issue:
"5.2.1 The
placement of NSIS Initiator, Forwarder, Responder MUST be free"
MUST be free of what?
Requested change:
5.2.1 The placement
of NSIS Initiator, Forwarder, and Responder anywhere
in the network MUST
be allowed"
Issue Number: 14
Issue Name: Rephrase
5.2.2
Submitter name:
Kuntal Chowdhury
Submitter email
address: kuntal@iqmail.net
Date first submitted:
03-01-22
Reference: -
Document:
draft-ietf-nsis-req-06.txt
Comment type: E
Priority:
Document Section:
5.2.2
Rationale/Explanation
of issue:
"5.2.2 No
constraint MUST be posed the signaling and NSIS Forwarders to
be in the data path.
"
Need to rephrase this
requirement.
Requested change:
5.2.2 There MUST not
be any constraint to always require the NSIS
forwarder to be on
the data path.
Issue Number: 15
Issue
Name: editorial nits
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: E
Priority: 3
Section:
Abstract, page 1 line 41
Rationale/Explanation
of issue:typo error "in recent year"
Section:
1, page 2 line 51
Rationale/Explanation
of issue:typo error "to t4est"
Requested
change:"to test"
Section:
1, page 3 line 3
Rationale/Explanation
of issue:typo error "requirement documents", "other
application"
Requested
change:"requirements document", "other applications"
Section:
2, page 3 line 14
Rationale/Explanation
of issue:text editing/formating
Requested
change:Need to have a formal section introduction or take it out
Section:
5.2.2
Rationale/Explanation
of issue: Typo error. "No constraint MUST be posed the
signaling
and NSIS Forwarders to
be in the data path."
Requested
change: could be simply reworded to "independence of the signaling
path
and the data path"
Section:
5.3.3 page 13 line 41
Rationale/Explanation
of issue: Typo error."the network nodes can locally
repair
this type error"
Requested change: "the network
nodes can locally repair this type of error"
Issue
Number: 16
Issue
Name: Simplify text on Control Information
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: E
Priority: 3
Section:
2, page 4 line 17
Rationale/Explanation
of issue: simplify the text and make it generic
"Control
Information: the information the governs for instance the QoS
treatment
to be applied to a flow or aggregate, including the service class,
flow
administration, and any associated security or accounting information."
Requested
change:"Control information: information that governs the
treatment
to be applied to a flow or aggregate"
Issue
Number: 17
Issue
Name: Text simplification
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: E
Priority: 3
Section:
3, page 5 line 10
Rationale/Explanation
of issue: simplify the text
"A
basic goal should be to re-use these wherever possible, and to focus
requirements
work at an early stage on those areas where a new solution is
needed
(e.g. an especially simple one). We also try to avoid defining
requirements
related to internal implementation aspects."
Requested
change:"A basis goal should be to re-use the proposed architecture
wherever
possible"
Issue
Number: 18
Issue
Name: NSIS Responder clarification
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: T
Priority: 2
Section:
3, page 6 line 29
Rationale/Explanation
of issue: What about the NSIS responder? we should not
impose
where that function is hosted
"The
placement of the NSIS Initiators and NSIS Forwarders is not fixed."
Requested
change: "The placement of the NSIS Initiators, responders and NSIS
Forwarders
is not fixed."
Issue
Number: 19
Issue
Name: Protection of Non-signaling message clarification
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: E
Priority: 3
Section:
3, page 8 line 39
Rationale/Explanation
of issue: " the protection of non-signaling messages "¦
corresponding
application layer protocol".
It
could confuse people on point #7 "protection of non-signaling messages is
outside
the scope of the protocol".
Requested
change:
Either
we put it in the annex as is or suggest to reword it as:
"The
NSIS Forwarder need to have sufficient information to be able to
uniquely
identify a specific user flow even when security mechanisms are
applied
to that flow"
Issue
Number: 20
Issue
Name: 5.1.1 clarification
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: T
Priority: 2
Section:
5.1.1
Rationale/Explanation
of issue: "MUST be applicable for different
technologies"
Isn"t the requirement about having different types of services
that
could be signaled with the NSIS protocol? It is probably best to reword
it
for more clarity
Issue
Number: 21
Issue
Name: 5.3.3 clarification
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: T
Priority: 2
Section:
5.3.3 page 14 line 3
Rationale/Explanation
of issue: "Service upgrade available: If a previously
requested
better service becomes available."
We
might want to have this notification sent even if the service was not
asked
for it. The decision of sending or not the notification is a policy
issue
but we need to make sure that we can send the notification.
Issue
Number: 22
Issue
Name: Rewording suggestions
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: E
Priority: 3
Section:
5.3.4 page 14 line 30
Rationale/Explanation
of issue: rewording - "to also get a description of
what
amount of resources a request is
possible"
Requested
change: "to also get a description of what amount of available
requested
resources are available"
Section:
5.4.1 page 15 line 14
Rationale/Explanation
of issue: rewording - "note that a provider or that
particular
services requested"
Requested
change: "note that the provider of the particular requested
service"
Section:
5.4.2 page 15 line 18
Rationale/Explanation
of issue: rewording - "SHOULD possible to add and
remove
local domain information"
Requested
change: "It SHOULD be possible to
add and remove local domain
information"
Issue
Number: 23
Issue
Name: Flow Bundling support
Submitter
name: Cedric Aoun
Submitter
email address: cedric.aoun@nortelnetworks.com
Date
first submitted: 22/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: T
Priority: 2
Section:
5.4.5 page 16 line 3
Rationale/Explanation
of issue: "However, the network MUST NOT know that a
relationship
between the grouped flows exists. There MUST NOT be any
transactional
semantic associated with the grouping. It is only meant for
optimization
purposes and each reservation MUST be handled separately from
each
other."
We
need to have a MAY for having semantics to group flows that are bundled.
I
agree that the flows could have independent properties and associated
resource
reservations could still be taken down or processed independently.
The
usefulness of grouping these flows is primarily to tear down all their
associated
states at the same time without repeating the tear down message
several
time (i.e. command aggregation) and to minimize the size of the
message
data.
Issue
Number: 24
Issue
Name: Modify text for application independence
Submitter
name: Vlora Rexhepi
Submitter
email address: Vlora.Rexhepi@eln.ericsson.se
Date
first submitted: 17/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: T
Priority: 2
Section:
5.1.7
If we consider the 2 layer-model and the
separation between
the transport protocol and the signaling
application we might
want to re-formulate the requirement on
"5.1.7 NSIS MUST be
application independent", such that it
is clear that this is
the
requirement about the higher than network layer applications.
My worry is related to the paragraph:
"The requirement relates to the way
the signaling interacts with
upper layer functions (users, applications,
and QoS administration),
and
lower layer technologies."
as the signaling application layer
functions can also be seen
as "upper layer functions", in
which case we can't say that the
protocol is application independent.
I suggest to change this into:
"The requirement relates to the way
the signaling interacts with
upper (than NSIS protocol) layer functions
(users, applications,
and QoS administration), and lower (than NSIS) layer
technologies."
Issue
Number: 25
Issue
Name: Missing Framework references
Submitter
name: Vlora Rexhepi
Submitter
email address: Vlora.Rexhepi@eln.ericsson.se
Date
first submitted: 17/01/2003
Reference:
none
Document:
draft-ietf-nsis-req-06.txt
Comment
type: T
Priority: 2
Section:
5.1, 5.5.4, 10,2
In Section 5 on Requirements, it is
written:
"This section defines more detailed
requirements for
a signaling solution, respecting the
framework,..."
framework is mentioned without any
reference, so it might
be confusing. This is also the case for
Section 5.1. 5.5.4
and 10.2 under 2).
Suggested change: add
references