Subject: [NSIS] Issues 8 - 14

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

Hi Kuntal,

Comments in line:

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

I think we need to say 

	"This may include 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.

OK

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

OK

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

We can try to add some.

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

OK

> 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"

How about:

	MUST be possible.

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

I am not sure still about this requirement, does anyone have comments?

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

---

From: Kuntal Chowdhury <[email-masked]>
Date: Thu, 23 Jan 2003 16:26:42 -0600

Hi John,

Please see my comments line.

Regards,
Kuntal

> allocation/de-allocation."

I agree. The "may" sounds better.

>  > network resources in the internet.

Thanks.

>  > in the network MUST be allowed"

Sounds good to me.