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

From: [email-masked]
Date: Thu, 13 May 2004 08:28:54 +0200

Hi Attila,

Thanks for your comments. Please see inline ...

Sven

Attila Báder (IJ/ETH)    <[email-masked]>@ietf.org on 12/05/2004
18:17:05

Sent by:    [email-masked]

To:    "'McDonald, Andrew'" <[email-masked]>, Sven VAN DEN
       BOSCH/BE/ALCATEL@ALCATEL, [email-masked], Georgios Karagiannis
       <[email-masked]>
cc:
Subject:    RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt +
       early

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,
>
> 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?

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

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.

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

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.

Sven>> I think this is a question for the working group that we should
discuss at the interim. I agree with you that the mechanisms you propose
can be used. However, we started with a more basic scenario and added the
open issue to see if there is consensus to go further.

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

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

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 May 2004 09:52:26 +0200

Hi Attila, Sven, Andrew

> open issue to see if there is consensus to go further.

Georgios: I agree with Attila when saying that if we want to use NSIS for
real applications carrying such info
is necessary. Therefore, it is important to discuss this issue at the
interim meeting.

Best Regards,
Georgios