Subject: RE: [NSIS] new version of draft (-01) submitted

From: "Freytsis, Ilya" <[email-masked]>
Date: Mon, 13 May 2002 16:28:16 -0400

Marcus,

Please receive my comment to the draft made from the point of view on NSIS
as a protocol (meta-protocol that can be instantiated in a number of
protocols). Requirements are viewed as requirements that have to be
satisfied by the protocols' semantics but may or may not be supported by the
particular implementation in the particular network parts:

Terminology
QoS Initiator definition calling for QI to invoke local QoS provisioning. I
think it is not always true (think application proxy). I suggest to slightly
change definition "... as well as possibly invoking local QoS provisioning
mechanisms"

Problem statement and scope
Discussing placement of QIs and QCs the draft presenting two extreme cases
(every router incorporates QI and QC; only end systems incorporate QI and
QC). I suggest adding another case when neither QI nor QC is on the data
path. This case actually depicted in the fig 2 from the scenario 8.9 -
trunking gateway with MGC acting as QI and separate (from MGC) QCs managing
resources of the domains along the data path.

Requirements
I think the language in this section should be change to stricter,
"requirement like". Like the one used in Ruediger's e-mails on operational
and error signaling requirements.
It seems to me that there is a number of requirements that nobody will be
able to tell if they are satisfied or not by the developed "product". In
particular it is applicable to the requirements from the section 5.6
Performance and open issue 33 (highest possible network utilization). 

I suggest reducing the number of sections in the Requirements section by
merging content of the section 5.4 Layering into the section 5.1
Architecture and Design.

Architecture and Design:
- Requirements 5.1.5 is pretty much covered in 5.1.1 and can be removed
- Requirements 5.2.2 is of architectural nature and belongs to the section
5.1.

Additional Information beyond signaling:
- Requirement 5.3.2. I understand that NSIS signaling should enable this
type of behavior but the behavior itself is service specific and out of NSIS
scope. For example, if in the scenario 8.9 (trunking gateway) the gateway
controller (QI) dies you may want to preserve resources allocated for the
active calls instead of releasing them. 
- Requirement 5.3.3. It is not clear what failure this requirement is
dealing with. Is it failure of NSIS signaling entities (QI, QC) or failure
in the data-forwarding plane (router)?

Open issue 28: I support this requirement.

Regards,
Ilya Freytsis

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: Friday, April 12, 2002 12:54 PM
To: [email-masked]
Subject: [NSIS] new version of draft (-01) submitted

Dear NSIS WG,

I have just now submitted a new version of the reqirements draft.
It is meant to be an intermediate version to give you an impression of what
has been going on in the last weeks.

Major changes include
- restructured the draft
- added an extensive list of open and closed isues, coming from
  various places.
    -please check them whether is something miosssing from the issues side
    -some have volunteered to help with some of the issue (see the mail
     "home work" addressed to those)
    -some of the closed issues can be used as a change log
- I currently see the following three areas, which are not covered
   - interaction with mobility and running signaling
     in mobile environements
   - security issues
   - fault handling issues

- I am sorry, I am not able to put the thing on a web-page for those, which
can not wait and want to work over the weekend :-)

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis