Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early

From: "McDonald, Andrew" <[email-masked]>
Date: Wed, 12 May 2004 16:47:18 +0100

Hi Attila,

Attila Báder (IJ/ETH) wrote:
> The first one is editorial: There are a lot of information that are
> repeated more times in the document: first in the Overview part then
> in the Design Decision and also in the Func. Spec. part, sometimes
> with very similar details. I know that there are a lot of aspects
> that should be described and it is difficult to handle it but I think
> the doc. would be much easier to read if this fractal-like structure
> could be eliminated.      

I think with all the changes in technical content, it has been difficult to keep everything in balance. It's probably heading in the right direction, but as things settle down it might be useful to have a purely editorial pass at some point.

Do you think a different overall structure is needed, or is it just a rebalancing of what text goes where?

> The second is related to bi-directional and receiver-initiated
> reservation. In both case it can happen that the receiver does not
> have the resource info for the reverse reservation but the sender has
> this info. There is a discussion in the open issues mentioning that
> this info may should be provided by a different application. However,
> QoS-NSLP provides two natural mechanisms to transmit this info: a)
> stacking two QSpec like in case of local QoS model example and b)
> sending a separate reserve message with a QSpec for the reverse path
> directly to the receiver (like in case of aggregation or reduced
> state examples). So I would suggest that QoS-NSLP support this
> function.          

Just because we can doesn't necessarily mean we should.

I think this is an architectural question. Should the QoS NSLP be involved in transporting end-to-end data of this sort, or is that outside our scope, and so something that should be done by some other mechanism? (this is a question of carrying something unchanged end-to-end, not AdSpec-like things)
[please read section 9.7 of the -03 draft to get the full question]

best regards,
Andrew

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

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Wed, 12 May 2004 18:17:05 +0200

Hi Andrew, see my comments inline,

Best regards, Attila

> -----Original Message-----
> From: McDonald, Andrew [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2004 5:47 PM
> To: Attila Báder (IJ/ETH); [email-masked]';
> [email-masked]; Georgios Karagiannis
> Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt +
> early
> 
> 
> Hi Attila,
> 
> I think with all the changes in technical content, it has 
> been difficult to keep everything in balance. It's probably 
> heading in the right direction, but as things settle down it 
> might be useful to have a purely editorial pass at some point.
> 
> Do you think a different overall structure is needed, or is 
> it just a rebalancing of what text goes where?

This latter one. If the number of subsection could be decreased, I think, would help. 

> I think this is an architectural question. Should the QoS 
> NSLP be involved in transporting end-to-end data of this 
> sort, or is that outside our scope, and so something that 
> should be done by some other mechanism? (this is a question 
> of carrying something unchanged end-to-end, not AdSpec-like things)

I think, if you want to use NSIS for real applications carrying such info cannot be avoided. I think NSIS should carry all info related to resource reservation. It can be included also into QSpec but I think it would be more natural to use stacking or send it in a separate QoS-NSLP message. 

> 
> best regards,
> Andrew
> 
> -- 
> 
> Visit our website at www.roke.co.uk
> 
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>

---

From: [email-masked]
Date: Thu, 13 May 2004 09:52:31 +0300

Hi Sven,

> Sven>> OK. We organised the document the way it is such that readers that
> are not interested in implementation but want to get a view on what QoS
> NSLP does and what mechanisms it uses only have to read the first sections.
> We look at the rebalance like you suggest next time.

I would think that having a protocol overview before delving into the
protocol details is a good thing, probably what is needed is just some
rebalancing of the text.

John