Subject: [NSIS] Reminder for WGLC for draft-ietf-nsis-qspec-15.txt

From: Martin Stiemerling <[email-masked]>
Date: Sun, 4 Mar 2007 22:06:53 +0100

Dear all,

This is just a friendly reminder for the QSPEC WGLC which runs until  
March 6th.

Thanks,

   Martin

Anfang der weitergeleiteten E-Mail:

> Von: Martin Stiemerling <[email-masked]>
> Datum: 20. Februar 2007 15:54:44 MEZ
> An: nsis <[email-masked]>
> Betreff: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt
>
> Dear all,
>
> I would like to start the working group last call for the QSPEC draft
> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt).
>
> The WGLC is starting today and will run for two weeks until Tuesday  
> Feb 6th.
>
> Please send your comments to the NSIS WG list.
>
>   Martin
>
> Anfang der weitergeleiteten E-Mail:
>
>> Von: <[email-masked]>
>> Datum: 16. Februar 2007 21:50:02 MEZ
>> An: <[email-masked]>
>> Kopie: <[email-masked]>
>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Next Steps in Signaling Working  
>> Group of the IETF.
>>
>> 	Title		: QoS NSLP QSPEC Template
>> 	Author(s)	: J. Ash, et al.
>> 	Filename	: draft-ietf-nsis-qspec-15.txt
>> 	Pages		: 54
>> 	Date		: 2007-2-16
>> 	
>> The QoS NSLP protocol is used to signal QoS reservations and is
>>    independent of a specific QoS model (QOSM) such as IntServ or
>>    DiffServ.  Rather, all information specific to a QOSM is  
>> encapsulated
>>    in a separate object, the QSPEC.  This document defines a template
>>    for the QSPEC including a number of QSPEC parameters.  The QSPEC
>>    parameters provide a common language to be re-used in several  
>> QOSMs
>>    and thereby aim to ensure the extensibility and  
>> interoperability of
>>    QoS NSLP.  The node initiating the NSIS signaling adds an  
>> initiator
>>    QSPEC, which indicates the QSPEC parameters that must be  
>> interpreted
>>    by the downstream nodes less the reservation fails, thereby  
>> ensuring
>>    the intention of the NSIS initiator is preserved along the  
>> signaling
>>    path.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the  
>> body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-ietf-nsis-qspec-15.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-nsis-qspec-15.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.

>
>
>
> [email-masked]
> NEC Europe Limited |
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
> Registered in England 2832014
>
>
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sun, 4 Mar 2007 21:39:43 -0500

Martin:
 
In addition to Georgio's comments, the following comments are provided:

1.	
	Extensions of QSPEC for implementation-specific value-based DSTE and Y.xxxx QOS-SLAs MUST be deleted.
2.	
	It had been explained in many emails (if needed, I can include those from the NSIS archives) that value-based QOS-SLAs do NOT need any NSIS QOS signaling messages as those SLAs have been created not to send any signaling messages in the first place because there is nothing to negotiate as those have followed a different models - know as service level agreements (SLAs). For example, OSP (Open Settlement Protocol) is used among the service providers for SLAs - a kind of QOS and other service provisioning aspects of SLAs are taken care of by using fixed-value based agreements.
3.	
	QOS model (QOSM) drafts like DiffServ and others are being written how QOS model-specific part will be used/extended by the QSPEC, and nothing has been done in this QSPEC draft to take care of the DIffServ and/or IntServ QOS models. This provides another basic reference why QOS-model-specific extensions must NOT be taken into account in this draft.

Some side comments:

1.	Is this the norm of the IETF that the names of the contributors MUST be written upfront of the RFC? If not, why is this being followed specific for this draft?
2.	Will anyone of this NSIS WG provide any testimony or proof that the persons whose names have been included as contributors in this draft? If not, how are those names being printed there? Instead, why have the members like Georgios, and others who contributed all along in this mailing list not included as contributors in this draft? Or, could you please see the NSIS email archives to find the proof who are the actual contributors?

Best regards,

Radhika

________________________________

From: [email-masked] on behalf of Martin Stiemerling
Sent: Sun 3/4/2007 4:06 PM
To: nsis
Subject: [NSIS] Reminder for WGLC for draft-ietf-nsis-qspec-15.txt 

Dear all,

Thanks,

   Martin

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 6 Mar 2007 13:51:15 -0000

hi,

here are some comments. most are minor.

robert h.

========================================================================
====

general: i think the document needs to be checked for consistency of
2119 capitalisation. some musts/shoulds should be MUSTs/SHOULDs and so
on. (I think actually the words themselves are right except where noted
below.)

p9 para 2 line 5 ("but they ..."): needs editorial fixing

s4.3 para 2 (and similarly later): surely not-understood non-mandatory
parameters MUST be ignored? is there any meaningful sense in which they
could not be?

s4.3.1 para 2 "mathematically complete": i have looked for a reference
for this for a while - imagine my disappointment when the citation
[WROCLAWSKI] resolves to 'TBD'! 

s4.3.1 final para: i would use a word other than 'composed' for the
first three instances ('input' and 'output'?)

s4.3.2 para 2: if the delay includes queuing, i would add this
explicitly to the 2nd sentence. (currently, it implies it is limited to
propagation and processing delays, and it is not obvious whether queuing
is a type of processing.) Also, it needs to be clear if it is the mean
queuing delay or some other statistic of the delay (since variability is
covered in the next paragraph under jitter).

s4.3.2 2nd-to-last para: "an QSPEC" --> "a QSPEC"

s4.3.3 para 1: i don't see how the second two sentences here relate to
TH directives. Could they be deleted? I think the message is already
stated earlier in the document.

s4.3.4: I could not follow this section. In particular, the example in
4.4 has the QNI populating the PHB value, not the downstream QNE as
stated here.

s4.4 (and later): there should be some reference to the QoS-NSLP
specification to clarify the meaning of the word 'tunnel'. It could
refer to tunneling the data+signalling, tunneling the signalling only,
or hiding the signalling from the interior some other way (e.g. using an
NSLPID which isn't understood in the interior). I'm not suggesting
actually defining/discussing all these in the QSPEC document, just
noting that the tunnel words as a shorthand may be misleading to people
who don't have all the context. You could use a word like 'hiding' and
refer to 3.3.1 of Qos-NSLP and 7.2 of GIST.

s5.1 last para: presumably this is saying that an edge node could use
both techniques, but not for the same traffic (what would be the point
of that?)

s5.2.1 para 1: presumably only understood parameters MUST be examined?

s5.2.2 last para: could say 'provides a bound' rather than unreliable.

s5.2.5: i think there should be some notes here pointing out that there
is some intelligence needed in mapping the E flags etc. from the inner
to the initiator Qspec. (Note that this *not* the same as Qspec mapping,
but there is at least some mapping to do - for example, there may be no
direct match between the parameters in the local and initiator Qspecs,
but that does not mean that no E flags should be raised in the latter.)

s5.3: i think that rather than describing the two cases as
sender/receiver-initiated, it would be better to describe these two
cases as a 2-way transaction and a 3-way transaction. It just so happens
that up to now it's natural to use the 2-way handshake for a
sender-initiated reservation and the 3-way handshake for a receiver
initiated one, because then in each case the first message in the
handshake is sent by the flow sender and this can set up the routing
state. However, logically GIST can (attempt to) set up the routing state
in the reverse direction, so you can for example have a
receiver-initiated reservation set up with the 2-way transaction. (this
would be the natural way to do a reservation for an inbound flow to a
mobile node from a mobility anchor, for example.) I don't think this
changes any of the text other than giving things different headings and
using the terms QNI/QNR rather than sender/receiver in the descriptions.

s5.3.2: Case 4 --> Case 3?

s5.3.5: I would delete the clause about pre-emption being based on the
Priority parameter. It implies that pre-emption is somehow
deterministic, whereas I would say that it is always a matter of QNE
policy, which could take all sorts of things into account (and the
values of the priority parameter in various messages are just some of
these).

s5.4 para 1: surely update to all QNEs is needed only if the parameter
is always used with M=1 and there is no fallback in response to error
conditions. (As written, this is much too pessimistic.)

s6.2.3 (and later): i would move the definition of the 'indeterminate'
encoding earlier, otherwise one is left wondering what this word means.
[there are also two typos here, flagand and flagflag.]

s6.2.5/6.2.6: remove references to values being measured in
microseconds.

s6.2.12: i think the initial layout diagram is confusing. it implied to
me that the PHB encoding is always a 6 bit field. Actually, the initial
diagram should be of a 16 bit field, and then three (rather than two)
layout options, for the three cases of prescribed value, value set, and
non-standard. And shouldn't the 'X' in the second two layout options
actually be a '1'?

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 7 Mar 2007 21:24:11 +0100

Hi,

I have found an editorial nit in Section 6.1 General QSPEC Formats.  
On page 28, after the Common QSPEC Header figure it says still QOSM  
ID instead of QSPEC type.

   Martin

Am 20.02.2007 um 15:54 schrieb Martin Stiemerling:

>> <ATT61320.TXT>
>> <draft-ietf-nsis-qspec-15_URL.DEFANGED-0>
>> <ATT61321.txt>
>
>
>

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Thu, 8 Mar 2007 14:54:46 -0600

Hi Robert,

Thanks a lot for the careful review.  Please see responses below. 

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 8:51 AM
> To: nsis
> Subject: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt
> 
> hi,
> 
> on. (I think actually the words themselves are right except 
> where noted below.)

OK.
 
> parameters MUST be ignored? is there any meaningful sense in 

OK.

> [WROCLAWSKI] resolves to 'TBD'! 

Agreed.  I've tried to run down a reference to the work that supports
this statement, but so far without success (I've emailed the possible
source of the analysis but so far haven't gotten a reply).  Lacking an
appropriate reference, the related text/reference will be removed.

> first three instances ('input' and 'output'?)

These is quite common terminology used in other RFCs to mean
'accumulated' values, see for example RFC 2210
http://www.ietf.org/rfc/rfc2210.txt?number=2210 and search the word
"composed" (object names even use the word).
 
> covered in the next paragraph under jitter).

The third sentence in the paragraph says "The mean delay reflects the
variable queuing delay that may be present."  I think that clarifies
your issues?
 
> s4.3.2 2nd-to-last para: "an QSPEC" --> "a QSPEC"

OK.
 
> stated earlier in the document.

I agree that this text may be a bit repetitious.  However, there was a
very long discussion regarding this text (see NSIS archive) and it was
agreed that this text was the resolution of the discussion.  I don't
think we can delete it.
 
> 4.4 has the QNI populating the PHB value, not the downstream QNE as

Good point.  I think the particular sentence could be clarified as
follows:

"Note that PHB class is normally set by a downstream QNE to tell the QNI
how to mark traffic to ensure treatment committed by admission control,
however, setting of the parameter by the QNI is not precluded."
 
> refer to 3.3.1 of Qos-NSLP and 7.2 of GIST.

OK, agree with your suggested re-phrasing.
 
> both techniques, but not for the same traffic (what would be the point

Good question.  This text was also added after much discussion on the
list.  I agree that it isn't clear how both techniques would be used at
the same time for the same flow.  We can add text to that effect,
however, I think it should be confirmed that these techniques are not
intended to be used *at the same time for the same flow*.  Perhaps
Georgios could verify this.
 
> s5.2.1 para 1: presumably only understood parameters MUST be examined?

Yes, good point.  This text needs to be clarified to say that only the
TMOD parameter and parameters marked with M=1 MUST be examined.
Parameters marked with M=0 SHOULD be examined if understood by the QNE.
 
> s5.2.2 last para: could say 'provides a bound' rather than unreliable.

OK.
 
> but that does not mean that no E flags should be raised in 

Agreed.  Any text suggestions would be appreciated here.
 
> using the terms QNI/QNR rather than sender/receiver in the 

OK with me to re-title these sub-sections as you suggest.
 
> s5.3.2: Case 4 --> Case 3?

Right.
 
> values of the priority parameter in various messages are just some of

Point taken.  The sentence could be changed as follows:
"A flow can be preempted by a QNE based on QNE policy, where a decision
to preempt a flow may account for various factors such as, for example,
the values of the QSPEC preemption priority and defending priority
parameters as described in Section 6.2.8."  

> conditions. (As written, this is much too pessimistic.)

Right.  This text should be deleted, a point that was raised on the list
at http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html (see
also the related comment at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html).
 
> [there are also two typos here, flagand and flagflag.]

OK on all.
 
> s6.2.5/6.2.6: remove references to values being measured in

Good catch.
 
> non-standard. And shouldn't the 'X' in the second two layout options

Good comments.  This should be clarified as follows:

Single PHB:

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DSCP      |0 0 0 0 0 0 0 0 0 0|
   +---+---+---+---+---+---+---+---+

Set of PHBs:

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DSCP      |0 0 0 0 0 0 0 0 1 0|
   +---+---+---+---+---+---+---+---+

Single non-standard PHB (experimental or local):

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PHD ID CODE      |0 0 0 1|
   +---+---+---+---+---+---+---+---+

Set of non-standard PHBs (experimental or local):

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PHD ID CODE      |0 0 1 1|
   +---+---+---+---+---+---+---+---+

Thanks,
Regards,
Jerry

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Thu, 8 Mar 2007 15:01:18 -0600

Hi Martin,

Good catch.

Thanks,
Jerry

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 9 Mar 2007 09:27:55 -0000

hi jerry,

a couple of followups: 

> From: ASH, GERALD R, ATTLABS [mailto:[email-masked]] 
> Sent: 08 March 2007 20:55
> To: Hancock, Robert; nsis
> Cc: ASH, GERALD R, ATTLABS
> Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt
> 
> Hi Robert,
> 
> > on. (I think actually the words themselves are right except where 
> > noted below.)
> 
> OK.
>  
> > parameters MUST be ignored? is there any meaningful sense in which 
> > they could not be?
> 
> OK.
> 
> Agreed.  I've tried to run down a reference to the work that 
> supports this statement, but so far without success (I've 
> emailed the possible source of the analysis but so far 
> haven't gotten a reply).  Lacking an appropriate reference, 
> the related text/reference will be removed.
> 
> http://www.ietf.org/rfc/rfc2210.txt?number=2210 and search 
> the word "composed" (object names even use the word).

maybe 'input composed' and so on; but i'm not that fussed
(i managed to work it out anyway)

> > explicitly to the 2nd sentence. (currently, it implies it 
> is limited 
> > to propagation and processing delays, and it is not obvious whether 
> > queuing is a type of processing.) Also, it needs to be 
> clear if it is 
> > the mean queuing delay or some other statistic of the delay (since 
> > variability is covered in the next paragraph under jitter).
> 
> The third sentence in the paragraph says "The mean delay 
> reflects the variable queuing delay that may be present."  I 
> think that clarifies your issues?

it's actually that sentence which caused the confusion. wouldn't it
be easier to have the second sentence say
"This delay results from the combination of speed-of-light propagation
delay, 
packet processing, and queueing." ?

> I agree that this text may be a bit repetitious.  However, 
> there was a very long discussion regarding this text (see 
> NSIS archive) and it was agreed that this text was the 
> resolution of the discussion.  I don't think we can delete it.

i agree the text is needed; it's just that it seems you already
have it in section 4.1.1 (in a more complete form, in fact)
which also seems the right place for it.

*** end of followup

robert h.

> "Note that PHB class is normally set by a downstream QNE to 
> tell the QNI how to mark traffic to ensure treatment 
> committed by admission control, however, setting of the 
> parameter by the QNI is not precluded."
>  
> > or hiding the signalling from the interior some other way 
> (e.g. using 
> > an NSLPID which isn't understood in the interior). I'm not 
> suggesting 
> > noting that the tunnel words as a shorthand may be misleading to 
> > people who don't have all the context. You could use a word like 
> > 'hiding' and refer to 3.3.1 of Qos-NSLP and 7.2 of GIST.
> 
> Good question.  This text was also added after much 
> discussion on the list.  I agree that it isn't clear how both 
> techniques would be used at the same time for the same flow.  
> We can add text to that effect, however, I think it should be 
> confirmed that these techniques are not intended to be used 
> *at the same time for the same flow*.  Perhaps Georgios could 
> verify this.
>  
> Yes, good point.  This text needs to be clarified to say that 
> only the TMOD parameter and parameters marked with M=1 MUST 
> be examined.
> > s5.2.5: i think there should be some notes here pointing out that 
> > there is some intelligence needed in mapping the E flags 
> etc. from the 
> > inner to the initiator Qspec. (Note that this *not* the 
> same as Qspec 
> > mapping, but there is at least some mapping to do - for 
> example, there 
> > may be no direct match between the parameters in the local and 
> > initiator Qspecs, but that does not mean that no E flags should be 
> > raised in the latter.)
> 
> > cases as a 2-way transaction and a 3-way transaction. It just so 
> > happens that up to now it's natural to use the 2-way 
> handshake for a 
> > state. However, logically GIST can (attempt to) set up the routing 
> > state in the reverse direction, so you can for example have a 
> > receiver-initiated reservation set up with the 2-way transaction. 
> > (this would be the natural way to do a reservation for an 
> inbound flow 
> > to a mobile node from a mobility anchor, for example.) I 
> don't think 
> > this changes any of the text other than giving things different 
> > headings and using the terms QNI/QNR rather than sender/receiver in 
> > the descriptions.
> 
> "A flow can be preempted by a QNE based on QNE policy, where 
> a decision to preempt a flow may account for various factors 
> such as, for example, the values of the QSPEC preemption 
> priority and defending priority parameters as described in 
> Section 6.2.8."  
> 
> Right.  This text should be deleted, a point that was raised 
> on the list at 
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.ht
> ml (see also the related comment at 
> > s6.2.12: i think the initial layout diagram is confusing. 
> it implied 
> > to me that the PHB encoding is always a 6 bit field. Actually, the 
> > initial diagram should be of a 16 bit field, and then three (rather 
> > than two) layout options, for the three cases of prescribed value, 
> > value set, and non-standard. And shouldn't the 'X' in the 
> second two 
> > layout options actually be a '1'?
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 9 Mar 2007 12:06:47 +0100

Hi all,

the WGLC for draft-ietf-nsis-qspec-15.txt ended on March 6th.

Thanks for all reviewers and the received comments.

There have been some issues to be solved, such as:
- editorial glitches and nits (noted by Jerry, Martin, etc)
- the QOSM-ID QSPEC-Type issue
- Robert's comments (currently worked on)

The editorial comments and Robert's comments are already fixed or in  
the process of being fixed.
The QOSM-ID and QSPEC-Type issue still needs some further  
discussions, but will hopefully also being fixed soon.

Thanks,

   Martin

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Sat, 10 Mar 2007 18:13:19 -0600

Hi Robert,

Please see below.

> (i managed to work it out anyway)

Would this revised text clarify:

   The output composed value is the minimum of the QNE's value and the
   input composed value for r, b, and p, and the maximum of the
   QNE's value and the input composed value for m.  This quantity,
   when composed end-to-end, informs the QNR (or QNI in a RESPONSE
   message) of the minimal TMOD resources along the path from QNI to
   QNR.

> delay, packet processing, and queueing." ?

Yes, that's fine, thanks for the text.

> which also seems the right place for it.

I agree that the 2nd paragraph in Section 4.1 says more or less the same
thing in a more complete form.  However, I think the intent was to
associate the text referring to 'RMF triggers' with the 'traffic
handling directives' parameters being discussed in Section 4.3.3.  So
perhaps we can just make a backward reference to Section 4.1, e.g.,

   In addition, as discussed in Section 4.1,
   an application MAY like to define RMF 
   triggers that cause the QoS NSLP to run semantics within the 
   underlying QoS NSLP signaling state and messaging processing rules, 
   as defined in Section 5.2 of [QoS-SIG].  Note, however, that new QoS 
   NSLP message processing rules can only be defined in Standards Track
   extensions to the QoS NSLP.

Thanks,
Jerry

---

From: "Robert Hancock" <[email-masked]>
Date: Sun, 11 Mar 2007 10:19:42 -0000

jerry,

these would all be fine by me.

thanks,

r. 

> Sent: 11 March 2007 00:13
> > > > s4.3.1 final para: i would use a word other than 'composed' for 
> > > >the  first three instances ('input' and 'output'?)
> 
> > > > explicitly to the 2nd sentence. (currently, it implies it is 
> > > > limited to propagation and processing delays, and it is not 
> > > > obvious whether queuing is a type of processing.) Also, 
> it needs 
> > > > to be clear if it is the mean queuing delay or some other 
> > > > statistic of the delay (since variability is covered in 
> the next 
> > > > paragraph under jitter).
> 
> > > The third sentence in the paragraph says "The mean delay reflects 
> > > the variable queuing delay that may be present."  I think that 
> > > clarifies your issues?
> 
> > it's actually that sentence which caused the confusion. 
> wouldn't it be 
> > easier to have the second sentence say "This delay results from the 
> > combination of speed-of-light propagation delay, packet processing, 
> > and queueing." ?
> 
> > > > s4.3.3 para 1: i don't see how the second two sentences here 
> > > > relate to TH directives. Could they be deleted? I think the 
> > > > message is already stated earlier in the document.
> 
> > > I agree that this text may be a bit repetitious.  
> However, there was 
> > > a very long discussion regarding this text (see NSIS 
> archive) and it 
> > > was agreed that this text was the resolution of the 
> discussion.  I 
> > > don't think we can delete it.
> 
> > i agree the text is needed; it's just that it seems you 
> already have 
> > it in section 4.1.1 (in a more complete form, in fact) which also 
> > seems the right place for it.
> 
> I agree that the 2nd paragraph in Section 4.1 says more or 
> less the same thing in a more complete form.  However, I 
> think the intent was to associate the text referring to 'RMF 
> triggers' with the 'traffic handling directives' parameters 
> being discussed in Section 4.3.3.  So perhaps we can just 
> make a backward reference to Section 4.1, e.g.,
>