Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

From: [email-masked]
Date: Wed, 8 Jan 2003 03:03:33 +0200

Dear all,

Marcus Brunner has submitted an updated version of the requirements document.  He feels that he has addressed all of the remaining open issues, and we feel that it is ready for WG last call.  There are a number of editorial nits, but otherwise the document is in good shape.

Therefore, I am asking the working group to review the document and submit any issues found.

The working group last call will last until Wednesday January 22nd, 4 PM Pacific Coast Time.

I will send a subsequent mail outlining the procedure for submitting issues.

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 10 Jan 2003 16:46:29 +0100

Hi all 

I have a first comment on draft-ietf-nsis-req-06.txt
related to Section 5.1.5.

Section 5.1.6 emphasizes that the NSIS protocol must support 
independence of signaling and provisioning paradigm.
If that is true I do not understand why then Section 5.1.5 
emphasizes that the NSIS protocol MUST 
reuse existing provisioning functions and protocols!

NSIS is a signaling protocol and it should actually not depend 
on any provisioning function or protocol. Therefore, I propose 
to remove Section 5.1.5.

Best Regards,
Georgios 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 8 januari 2003 2:04
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

Dear all,

thanks,
John

---

From: [email-masked]
Date: Sat, 11 Jan 2003 08:54:34 +0200

Hi Georgios,

> reuse existing provisioning functions and protocols!

What I think is meant is that NSIS protocol SHOULD NOT define 
new provisioning paradigms, but try to re-use existing ones.
 
> on any provisioning function or protocol. Therefore, I propose 

I don't think it is meant that NSIS MUST depend on a provising
function or paradigm.

Does this make sense?

John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 13 Jan 2003 09:52:11 +0100

John,

my remarks in line.

Regards, Rüdiger

| > I have a first comment on draft-ietf-nsis-req-06.txt
| > related to Section 5.1.5.
| > 
| > Section 5.1.6 emphasizes that the NSIS protocol must support 
| > independence of signaling and provisioning paradigm.
| > If that is true I do not understand why then Section 5.1.5 
| > emphasizes that the NSIS protocol MUST 
| > reuse existing provisioning functions and protocols!
| 
| What I think is meant is that NSIS protocol SHOULD NOT define 
| new provisioning paradigms, but try to re-use existing ones.

Only SHOULD NOT? The suggested new charter says: "It is a 
non-goal of the working group to develop new resource allocation 
protocols. Resource reservation and traffic engineering are out 
of scope of this working group."
"Should not" means that NSIS is allowed to work on provisioning 
if that is felt to be required. Could you clarify what kind of
work on provivioning is within scope and the relation of this to 
the charter?

should the following be correct,

"Specification of any provisioning function is out
of scope of the NSIS WG. Any protocols developed by
NSIS may assume existing standard-provisioning 
functions if information about provisioning 
mechanisms is required for the protocol design."

5.1.5. could be removed and the above could be inserted wherever it
fits (a charter non goal with some explanation or a requirement).

If wording of the text I proposed may be misleading, it should be 
improved. I hope the sense gets through. "Provisioning" my be 
replaced by "resource allocation" and/or "TE". Or is there a 
significant difference between provisioning and resource allocation? 
Where is it defined?
  
| > NSIS is a signaling protocol and it should actually not depend 
| > on any provisioning function or protocol. Therefore, I propose 
| > to remove Section 5.1.5.
| 
| I don't think it is meant that NSIS MUST depend on a provising
| function or paradigm.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Mon, 13 Jan 2003 10:06:19 +0100

Hi John,

|I don't think it is meant that NSIS MUST depend on a provising
|function or paradigm.

True. So why a "MUST" for the NSIS protocol to reuse the existing 
provisioning functions and protocols? If the protocol is independent
of these functions then it can be used with any provisioning functions
and protocols, existing and new ones.

Regards,
Vlora

---

From: [email-masked]
Date: Mon, 13 Jan 2003 11:36:04 +0200

Hi Vlora,

> and protocols, existing and new ones.

I think it is meant that it MUST be possible to use existing provishing
protocols, which I think is reasonable.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 13 Jan 2003 12:04:28 +0100

Hi John

>> protocols, which I think is reasonable.

Yes, but does this also mean that it is not allowed to use 
new provisioning functions?
If that is true then we actually limit the modularity and flexibility
capabilities of the NSIS protocol.

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 13 januari 2003 10:36
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

Hi Vlora,

---

From: [email-masked]
Date: Mon, 13 Jan 2003 13:40:07 +0200

Hi,

> new provisioning functions?

We are not defining new provisioning functions now in NSIS, so
this is out of scope.  We are not preventing the use of new
mechanisms, it is just out of scope.

> capabilities of the NSIS protocol.

So, I propose we change the text from:

  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'.) 

This text puts no restriction on future protocol use or evolution.

best regards, 

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 13 Jan 2003 14:25:57 +0100

Hi John

Thank you!
I totally agree with your proposal!

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 13 januari 2003 12:40
To: [email-masked]; [email-masked]
Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

Hi,

    

to:

best regards, 

John

---

From: [email-masked]
Date: Mon, 13 Jan 2003 15:27:29 +0200

Hi Melinda,

> > I agree with you - I meant provisioning mechanisms are currently
> > out of scope for NSIS.  The requirement should probably say that
> > the work MUST be able to re-use existing mechanisms.  
> 
> If it's out-of-scope, what are the consequences of just
> dropping it?  

Dropping it may imply that provisioning mechanisms could be considered part 
of an NSIS protocol.

> If there are consequences, doesn't that imply that it's in scope?

How to re-use provisioning mechaisms is in scope, developing new ones
is not in scope.

John

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Fri, 17 Jan 2003 15:06:35 +0100

Hi,

Some minor comments on the draft:

1. 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).

2. 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."
   
   Does this make sense?

Regards,
Vlora

---

From: [email-masked]
Date: Wed, 22 Jan 2003 09:22:43 +0100

John, 

here are some of my issues to the document. Sorry for posting them late.

Issue Name: 
Submitter name: Anders Bergsten
Submitter email address: [email-masked]
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 Name: 
Submitter name: Anders Bergsten
Submitter email address: [email-masked]
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 contain 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 contraint 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 contraint 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 equivilant term for AS-path).

Issue Name: 
Submitter name: Anders Bergsten
Submitter email address: [email-masked]
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 by whom the reply should be sent, 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 interpretes 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 Name: 
Submitter name: Anders Bergsten
Submitter email address: [email-masked]
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 maintainance 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 r!
elationship 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. 

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 implications 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 interprete them as "hard" requirements, but rather as indications of requirement. 

Anders

> Sent: den 8 januari 2003 02:04
> To: [email-masked]
> Cc: [email-masked]
> Marcus Brunner has submitted an updated version of the 
> requirements document.  He feels that he has addressed all of 
> the remaining open issues, and we feel that it is ready for 
> WG last call.  There are a number of editorial nits, but 
> otherwise the document is in good shape.
>

---

From: Kuntal Chowdhury <[email-masked]>
Date: Wed, 22 Jan 2003 16:46:41 -0600

Hi all,
Here are a few issues that I found so far. IMHO, the document needs a 
through editorial scrub.

Regards,
Kuntal

Issue Name:
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
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 Name:
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
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 Name:
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
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 Name:
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
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 Name:
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
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 Name:
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
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 Name:
Submitter name: Kuntal Chowdhury
Submitter email address: [email-masked]
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.

---

From: [email-masked]
Date: Thu, 23 Jan 2003 10:37:16 +0200

Assigned issue 1:

http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm

> From: ext Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 13 January, 2003 15:26
> To: Loughney John (NRC/Helsinki); [email-masked]

---

From: [email-masked]
Date: Thu, 23 Jan 2003 10:37:49 +0200

Assigned issues 24 & 25:

> From: ext Vlora Rexhepi (ELN) [mailto:[email-masked]]
> Sent: 17 January, 2003 16:07
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 23 Jan 2003 10:38:22 +0200

Assigned issue 7:

-----Original Message-----
From: ext Louis-Nicolas Hamer [mailto:[email-masked]]
Sent: 22 January, 2003 22:27
To: [email-masked]
Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

All, 

Issue Name: ? 
Submitter name: Louis-Nicolas Hamer 
Submitter email address: [email-masked] 
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.

Cheers, 

L-N 

> From: [email-masked] [ mailto:[email-masked]] 
> Sent: Wednesday, January 22, 2003 3:23 AM 
> To: [email-masked]; [email-masked] 
> 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 Name: 
> Rationale/Explanation of issue: The section contain 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 contraint 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 contraint 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 
> equivilant term for AS-path). 
> 
> 
> Issue Name: 
> Rationale/Explanation of issue: "A request for service MUST 
> be answered at least with a yes or no". This does not state 
> by whom the reply should be sent, 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 interpretes 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 Name: 
> 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 maintainance 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 r! elationship 
> 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. 
> 
> 
> 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 implications 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 interprete them as "hard" 
> requirements, but rather as indications of requirement. 
> 
> Anders 
> 
> > From: [email-masked] [ mailto:[email-masked]]

---

From: [email-masked]
Date: Thu, 23 Jan 2003 10:38:59 +0200

Assigned issues 2 - 6:

> From: ext [mailto:[email-masked]]
> Sent: 22 January, 2003 10:23
> harder to solve than allowing a node to know a relationship 
> between flows.

---

From: [email-masked]
Date: Thu, 23 Jan 2003 10:39:30 +0200

Assigned issues 8 - 14:

> From: ext Kuntal Chowdhury [mailto:[email-masked]]
> Sent: 23 January, 2003 00:47
> To: [email-masked]
> Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt
> 
> 
> Hi all,

---

From: [email-masked]
Date: Thu, 23 Jan 2003 10:54:09 +0200

Hi Kuntal,

In principle, I like this generalization - what do others thik?

br,
John

> Sent: 23 January, 2003 00:40
> To: [email-masked]
> 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.
> 
> Regards,
> Kuntal
> 
> 
> 
> Hamer, Louis-Nicolas [CAR:DR13:EXCH] wrote:
> > All,
> > 
> > Issue Name: ?
> > could fit into the 3GPP release 6, which is still not yet 
> defined by the 
> > way.
> > 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.
> > 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)
> > if the contributors contacted me directly or through the 
> mailing list. 
> > Unless the chair (or someone else) has a better way forward.
> > 
> > Cheers,
> > 
> > L-N
> > 
> > 
> > 
> >  > From: [email-masked] 
> [mailto:[email-masked]]

---

From: [email-masked]
Date: Thu, 23 Jan 2003 10:01:15 +0100

Hi all,

I have been contributing on the section on UMTS. Looking at it again
I agree it is indeed a somewhat limited example. Therefore, I propose
to all possible usages. In that case I think we should mention:
1. NSIS initiator in the UE
2. NSIS initiator in the Access gateway
3. NSIS initiator in the PCF

Also, I agree also that we should generalize the example beyond UMTS,
e.g. 3G wireless in general. Any input on this text would be welcomed.

What do you think?

regards,
Maarten

Kuntal Chowdhury <[email-masked]>@ietf.org on 22/01/2003 23:39:39

Sent by:    [email-masked]

To:    [email-masked]
cc:

Hi all,
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:

                            +--------+

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.

Regards,
Kuntal

Hamer, Louis-Nicolas [CAR:DR13:EXCH] wrote:
> if the contributors contacted me directly or through the mailing list.
>  > From: [email-masked] [mailto:[email-masked]]

---

From: "Louis-Nicolas Hamer" <[email-masked]>
Date: Thu, 23 Jan 2003 09:36:01 -0500

Maarten,

Sounds like we are in agreement. I also agree with the generalizations to
cover cdma2000 from Kuntal.
I will try to sync up with Kuntal to generate
some proposed text to generalize the example.

Cheers,

L-N

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, January 23, 2003 4:01 AM
> To: [email-masked]
> I have been contributing on the section on UMTS. Looking at 
> it again I agree it is indeed a somewhat limited example. 
> Therefore, I propose to all possible usages. In that case I 
> think we should mention: 1. NSIS initiator in the UE 2. NSIS 
> initiator in the Access gateway 3. NSIS initiator in the PCF
> 
> Also, I agree also that we should generalize the example 
> beyond UMTS, e.g. 3G wireless in general. Any input on this 
> text would be welcomed.
> 
> What do you think?
> 
> regards,
> Maarten
> 
> 
> 
> 
> 
> 
> 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:
> 
>                             +--------+
> 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.
> 
> Regards,
> Kuntal
> 
> 
> 
> 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
> > propose we clean it up:
> > 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.
> >
> > Cheers,
> >
> > L-N
> >
> >
> >