Subject: [NSIS] comments on draft-ietf-nsis-req-06.txt

From: "Cedric Aoun" <[email-masked]>
Date: Thu, 23 Jan 2003 01:22:28 +0100

Hi,
I have some comments on the draft, sorry for being late ...

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
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"
Requested change:"in the recent year"

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
Date first submitted: 22/01/2003 
Reference: none 
Document: draft-ietf-nsis-req-06.txt 
Comment type: E 
Priority:  3  
Section: 1, page 2 line 51
Rationale/Explanation of issue:typo error "to t4est"
Requested change:"to test"

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
Date first submitted: 22/01/2003 
Reference: none 
Document: draft-ietf-nsis-req-06.txt 
Comment type: E 
Priority:  3  
Section: 1, page 3 line 3
Rationale/Explanation of issue:typo error "requirement documents", "other
application"
Requested change:"requirements document", "other applications"

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
Date first submitted: 22/01/2003 
Reference: none 
Document: draft-ietf-nsis-req-06.txt 
Comment type: E 
Priority:  3  
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

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
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 Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
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 Name: ? 
Submitter name: Cedric Aoun
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: 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 Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
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 Name: ? 
Submitter name: Cedric Aoun
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: 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 Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
Date first submitted: 22/01/2003 
Reference: none 
Document: draft-ietf-nsis-req-06.txt 
Comment type: E 
Priority:  3  
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"

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
Date first submitted: 22/01/2003 
Reference: none 
Document: draft-ietf-nsis-req-06.txt 
Comment type: E 
Priority:  3  
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 Name: ? 
Submitter name: Cedric Aoun
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: 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 Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
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”

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
Date first submitted: 22/01/2003 
Reference: none 
Document: draft-ietf-nsis-req-06.txt 
Comment type: E 
Priority:  3  
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”

Issue Name: ? 
Submitter name: Cedric Aoun
Submitter email address: [email-masked] 
Date first submitted: 22/01/2003 
Reference: none 
Document: draft-ietf-nsis-req-06.txt 
Comment type: E 
Priority:  3  
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 Name: ? 
Submitter name: Cedric Aoun
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: 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.

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

---

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

Assigned issues 15 - 23:

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

> -----Original Message-----
> From: ext Cedric Aoun [mailto:[email-masked]]
> Sent: 23 January, 2003 02:22
> To: [email-masked]'
> Subject: [NSIS] comments on draft-ietf-nsis-req-06.txt
> 
> 
> Hi,
> wherever possibleâEUR
> âEURoeThe placement of the NSIS Initiators and NSIS Forwarders 
> is not fixed.âEUR
> Requested change: âEURoeThe placement of the NSIS Initiators, 
> responders and NSIS
> Forwarders is not fixed.âEUR
> 
> 
> Issue Name: ? 
> Rationale/Explanation of issue: âEURoe the protection of 
> non-signaling messages âEUR¦
> corresponding application layer protocolâEUR.
> It could confuse people on point #7 âEURoeprotection of 
> non-signaling messages is
> outside the scope of the protocolâEUR.
> Requested change:
> âEURoeThe NSIS Forwarder need to have sufficient information to 
> be able to
> applied to that flowâEUR
> Rationale/Explanation of issue: âEURoeMUST be applicable for different
> technologiesâEUR IsnâEUR(tm)t the requirement about having 
> different types of services
> Rationale/Explanation of issue: Typo error.âEURoeNo constraint 
> MUST be posed the
>      be in the data path.âEUR
> Rationale/Explanation of issue: Typo error.âEURoethe network 
> nodes can locally
> repair this type errorâEUR
> Requested change: âEURoethe network nodes can locally repair 
> this type of errorâEUR
> 
> Issue Name: ? 
> Rationale/Explanation of issue: âEURoeService upgrade available: 
> If a previously
> requested better service becomes available.âEUR
> Rationale/Explanation of issue: rewording - âEURoeto also get a 
> description of
> what amount of  resources a request is possibleâEUR
> Requested change: âEURoeto also get a description of what amount 
> of available
> requested resources  are availableâEUR
> 
> 
> 
> Issue Name: ? 
> Rationale/Explanation of issue: rewording - âEURnote that a 
> provider or that
> particular services requestedâEUR 
> Requested change: âEURoenote that the provider of the particular 
> requested
> serviceâEUR
> 
> 
> 
> 
> Issue Name: ? 
> Rationale/Explanation of issue: rewording - âEURSHOULD 
> possible to add and
> informationâEUR
> Rationale/Explanation of issue: âEURoeHowever, the network MUST 
> NOT know that a
> each other.âEUR