Subject: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

From: Alvaro Retana <[email-masked]>
Date: Wed, 15 Aug 2018 16:53:26 -0400

Dear authors:

I just finished reading this document.  I have several comments and
concerns that I included inline below.

One item that I want to highlight here is the lack of specific procedures
defined to handle the cases of multiple advertisements (in both §2 and
§3).  Please take a look at my specific comments below -- in short, a clear
specification is required for proper interoperability.  I will wait for (at
least) this item to be addressed before starting the IETF LC.

Thanks!

Alvaro.

[The line numbers came from the idnits output.]

...
76 1.  Introduction
...
95   links in the network MSD is relevant, MSD capabilites should be
96   advertised by every IS-IS router in the network.

[nit] s/capabilites/capabilities

...
109   or SIDs associated with another dataplane e.g., IPv6.  Although MSD
110   advertisements are associated with Segment Routing, the
111   advertisements MAY be present even if Segment Routing itself is not
112   enabled.

[minor] Given that you're using Normative language...  It would be nice if
you expanded on the use of the MSD in a non-SR network.  Something simple
such as "a SID and a label are the same thing" would be enough.

114 1.1.  Conventions used in this document

116 1.1.1.  Terminology

[minor] Except for BMI/MSD, the other terms are not definitions, just
expansions.  Some of the abbreviations are already included in the RFC
Editor Abbreviations List [1].  In general, it would be better to just
expand on first use (BGP-LS, for example, is used *before* this section)
than to have this section with expansions.

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

...
147 2.  Node MSD Advertisement
...
156          0                   1
157          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

159         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
160         |    Type       |   Length      |
161         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
162         |   MSD-Type    | MSD Value     |
163         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
164         //     ...................     //
165         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
166         |   MSD-Type    | MSD Value     |
167         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

169                        Figure 1: Node MSD Sub-TLV

171   Type: 23 (allocated by IANA via the early assignment process)

173   Length: variable (minimum of 2, multiple of 2 octets) and represents
174   the total length of value field.

[nit] ...in octets (?).

176   Value: field consists of one or more pairs of a 1 octet MSD-Type and
177   1 octet MSD-Value.

[nit] There is no "Value" field illustrated above.  You might want to
reword a little.

[nit] The figure says "MSD Value", but the text talks about "MSD-Value".

...
191   If there exist multiple Node MSD advertisements for the same MSD-Type
192   originated by the same router, the procedures defined in [RFC7981]
193   apply.

[major] Does this text refer to multiple node MSD sub-TLVs (inside the
same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type
(included multiple times in a node MSD sub-TLV), or both?

[major] The only relevant text I can find in rfc7981 is this:

   Where a receiving system has two copies of an IS-IS Router CAPABILITY
   TLV from the same system that have conflicting information for a
   given sub-TLV, the procedure used to choose which copy shall be used
   is undefined.

I then don't know how to handle the multiple advertisements.  Please point
me in the right direction.

195 3.  Link MSD Advertisement

197   The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
198   223 to carry the MSD of the interface associated with the link.  MSD
199   values may be learned via a hardware API or may be provisioned.

[nit] A reference to the appropriate RFCs would be nice.

201         0                   1
202         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

204         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
205         |    Type       |   Length      |
206         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
207         |   MSD-Type    | MSD Value     |
208         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
209         //     ...................     //
210         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
211         |   MSD-Type    | MSD Value     |
212         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

214                        Figure 2: Link MSD Sub-TLV

216   Type: 15 (allocated by IANA via the early assignment process)

218   Length: variable (minimum of 2, multiple of 2 octets) and represents
219   the total length of value field.

[nit] ...in octets (?).

221   Value: consists of one or more pairs of a 1 octet MSD-Type and 1
222   octet Value.

[nit] There is no "Value" field illustrated above.  You might want to
reword a little.

[nit] The figure says "MSD Value", but the text talks about "Value".

...
235   If multiple Link MSD advertisements for the same MSD Type and the
236   same link are received, the procedure used to select which copy is
237   used is undefined.

[major] Does this text refer to multiple link MSD sub-TLVs (inside the
same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type
(included multiple times in a link MSD sub-TLV), or both?

[major] Without a procedure "it is unlikely that multiple implementations
of the specification would interoperate" [2].

[2] https://www.ietf.org/blog/discuss-criteria-iesg-review/

239 4.  Using Node and Link MSD Advertisements

[major] After reading this section, I still don't know how do use the
advertisements.  What should a receiver do with the values?  Maybe the use
is constrained to a controller...maybe the exact operation is our of the
scope of this document.  Either way, please say something.

241   When Link MSD is present for a given MSD type, the value of the Link
242   MSD MUST take preference over the Node MSD.  When a Link MSD type is
243   not signalled but the Node MSD type is, then the Node MSD type value
244   MUST be considered as the MSD value for that link.

[nit] s/signalled/signaled

...
258 5.  Base MPLS Imposition MSD

260   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
261   labels a node is capable of imposing, including all
262   service/transport/special labels.

264   Absence of BMI-MSD advertisements indicates solely that the
265   advertising node does not support advertisement of this capability.

[major] The MSD Types are applicable for both nodes and links, right?  The
description above only talks about nodes -- what about links?

267 6.  IANA Considerations

269   This document requests IANA to allocate a sub-TLV type for the new
270   sub TLV proposed in Section 2 of this document from IS-IS Router
271   Capability TLV Registry as defined by [RFC7981].

[minor] The registry is called "Sub-TLVs for TLV 242 (IS-IS Router
CAPABILITY TLV)". [3]

[3]
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242

...
303   This document requests creation of an IANA managed registry under a
304   new category of "Interior Gateway Protocol (IGP) Parameters" IANA
305   registries to identify MSD types as proposed in Section 2 and
306   Section 3.  The registration procedure is "Expert Review" as defined
307   in [RFC8126].  Suggested registry name is "IGP MSD Types".  Types are
308   an unsigned 8 bit number.  The following values are defined by this
309   document

[nit] s/under a new category/under the category

[major] This creation of the registry needs to include the "required
documentation and review criteria, giving clear guidance to the designated
expert" -- please see §4.5 in rfc8126.

311      Value     Name                             Reference
312      -----     ---------------------            -------------
313      0         Reserved                         This document

[major] 0 is not Reserved, but has a specific meaning (from §2 and §3).

314      1         Base MPLS Imposition MSD         This document
315      2-250     Unassigned                       This document
316      251-254   Experimental                     This document
317      255       Reserved                         This document

319                  Figure 6: MSD Types Codepoints Registry

321 7.  Security Considerations

323   Security considerations as specified by [RFC7981] are applicable to
324   this document.

326   Advertisement of the additional information defined in this document
327   that is false, e.g., an MSD that is incorrect, may result in a path
328   computation failing, having a service unavailable, or instantiation
329   of a path that can't be supported by the head-end (the node
330   performing the imposition).

[major] rfc7981 says that "specifications based on this mechanism need to
describe the security considerations around the disclosure and modification
of their information".  I think that the paragraph above applies also to
modification.  What about disclosure?

...
364 10.2.  Informative References

[major] rfc8126 should be Normative.

...
390   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
391              Writing an IANA Considerations Section in RFCs", BCP 26,
392              RFC 8126, DOI 10.17487/RFC8126, June 2017,
393              <https://www.rfc-editor.org/info/rfc8126>.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 15 Aug 2018 22:51:36 +0000

Alvaro –

A very thorough review – thanx.

Jeff has the pen – but I think he is on holiday at the moment – so there may be a short delay as regards a new version.
I will confine myself to comments on the non-editorial issues.
Inline.

From: Alvaro Retana <[email-masked]>
Sent: Wednesday, August 15, 2018 1:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Christian Hopps <[email-masked]>
Subject: AD Review of draft-ietf-isis-segment-routing-msd-13

Dear authors:

I just finished reading this document.  I have several comments and concerns that I included inline below.

One item that I want to highlight here is the lack of specific procedures defined to handle the cases of multiple advertisements (in both §2 and §3).  Please take a look at my specific comments below -- in short, a clear specification is required for proper interoperability.  I will wait for (at least) this item to be addressed before starting the IETF LC.

Thanks!

Alvaro.

...
76       1.  Introduction
...

...

[minor] Given that you're using Normative language...  It would be nice if you expanded on the use of the MSD in a non-SR network.  Something simple such as "a SID and a label are the same thing" would be enough.

116     1.1.1.  Terminology

[minor] Except for BMI/MSD, the other terms are not definitions, just expansions.  Some of the abbreviations are already included in the RFC Editor Abbreviations List [1].  In general, it would be better to just expand on first use (BGP-LS, for example, is used *before* this section) than to have this section with expansions.

...

[nit] ...in octets (?).

[nit] There is no "Value" field illustrated above.  You might want to reword a little.

...

[major] Does this text refer to multiple node MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a node MSD sub-TLV), or both?

[Les:] It really doesn’t matter. If you have two advertisements for the same MSD type from the same source then the procedures defined in RFC 7981 apply. It does not matter whether you find the advertisements in the same sub-TLV, in the same Router Capabilities TLV but different sub-TLVs, or in different Router Capabilities TLVs(sic).

[Les:] Your searching skills are excellent. ☺
RFC 7981 declined to define procedures for reasons which are explained in the three paragraphs prior to the one you have quoted.
If you have a problem with that please raise it in the context of RFC 7981 – not in the context of this draft.

I then don't know how to handle the multiple advertisements.  Please point me in the right direction.

[Les:] You are asking for an RFC reference for each of the mentioned TLV types (22, 23,…)???
Given that information is readily available here:  https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml why should we clutter a draft with duplicate info??

201             0                   1

[nit] ...in octets (?).

[nit] There is no "Value" field illustrated above.  You might want to reword a little.

...

[major] Does this text refer to multiple link MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a link MSD sub-TLV), or both?

[Les:] As with node MSD, it does not matter. What matters is that you have duplicate advertisements for the same link and MSD type.
Ohhh…and these advertisements are not in Router Capability TLV. ☺

[major] Without a procedure "it is unlikely that multiple implementations of the specification would interoperate" [2].

[Les:] The issue is not interoperability but that you do not know which one is correct. So no matter which one you choose you might use a value that is either not supported by the advertising node or limits label imposition unnecessarily.
I really don’t think there is an interoperability issue here.

[major] After reading this section, I still don't know how do use the advertisements.  What should a receiver do with the values?  Maybe the use is constrained to a controller...maybe the exact operation is our of the scope of this document.  Either way, please say something.

...

[major] The MSD Types are applicable for both nodes and links, right?  The description above only talks about nodes -- what about links?

[Les:] This section is not specific to link advertisements or node advertisements. It is talking about what it means when there is no applicable advertisement of BMI-MSD.
What is an applicable advertisement? That is explained in Section 4.
For a given link I either have an advertisement for that link or I have a node advertisement. If I have neither, I have no information and so you can infer that the node “declined to state”.

[minor] The registry is called "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)". [3]

[3] https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242

...

[major] This creation of the registry needs to include the "required documentation and review criteria, giving clear guidance to the designated expert" -- please see §4.5 in rfc8126.

[Les:] Guidance for Designated Experts – at least for IS-IS codepoints – has been defined in RFC 7170. Would it be sufficient to refer to that document and state that it applies in this case as well??
(I sure hope so. ☺ )

311          Value     Name                             Reference

[Les:] I am confused by your comment.
What is being reserved is the value “0” as an MSD-Type (See Figures 1 and 2) – not 0 as an MSD-Value.
Please help me to understand what text in the draft is in conflict??

[major] rfc7981 says that "specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information".  I think that the paragraph above applies also to modification.  What about disclosure?

[Les:]I think the same issues apply to disclosure. How about if we added:

“The presence of this information also may inform an attacker of how to induce any of the aforementioned conditions.”

???

   Les

...

...

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 15 Aug 2018 15:53:19 -0700

I’m almost ready with OSPF,  let’s take it from there

Cheers,

Jeff

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wednesday, August 15, 2018 at 15:51
To: Alvaro Retana <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Christian Hopps <[email-masked]>
Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13
Resent-From: <[email-masked]>
Resent-To: Jeff Tantsura <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wed, 15 Aug 2018 15:51:43 -0700 (PDT)

Alvaro –

Inline.

Dear authors:

Thanks!

Alvaro.

...

76       1.  Introduction

...

...

112       enabled.

116     1.1.1.  Terminology

...

...

156              0                   1

160             |    Type       |   Length      |

[nit] ...in octets (?).

177       1 octet MSD-Value.

...

193       apply.

 

   is undefined.

[Les:] Your searching skills are excellent. J

 

201             0                   1

205             |    Type       |   Length      |

[nit] ...in octets (?).

222       octet Value.

...

237       used is undefined.

Ohhh…and these advertisements are not in Router Capability TLV. J

 

 

...

...

309       document

(I sure hope so. J )

311          Value     Name                             Reference

324       this document.

???

   Les

...

...

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 20 Aug 2018 18:15:20 +0000

Alvaro –

V14 of the draft has been posted addressing your comments – subject to my responses previously sent.

Please let us know if this is sufficient or you still have concerns which need to be addressed.

   Les

From: Les Ginsberg (ginsberg)
Sent: Wednesday, August 15, 2018 3:52 PM
To: Alvaro Retana <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Christian Hopps <[email-masked]>
Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13

Alvaro –

From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 15, 2018 1:53 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
Subject: AD Review of draft-ietf-isis-segment-routing-msd-13

Dear authors:

Thanks!

Alvaro.

...
76       1.  Introduction
...

...

116     1.1.1.  Terminology

...

[nit] ...in octets (?).

...

201             0                   1

[nit] ...in octets (?).

...

...

...

311          Value     Name                             Reference

???

   Les

...

...

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 29 Aug 2018 09:53:49 -0700

On August 15, 2018 at 6:51:39 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

Les:

Hi!

You and I had an off-line conversation about the topic of multiple
advertisements.  I’m replying with similar comments to close the loop with
everyone else.

There are also a couple more comments after that.

Thanks!

Alvaro.

...

...

191       If there exist multiple Node MSD advertisements for the same
MSD-Type

193       apply.

[Les:] It really doesn’t matter. If you have two advertisements for the
same MSD type from the same source then the procedures defined in RFC 7981
apply. It does not matter whether you find the advertisements in the same
sub-TLV, in the same Router Capabilities TLV but different sub-TLVs, or in
different Router Capabilities TLVs(sic).

   is undefined.

RFC 7981 declined to define procedures for reasons which are explained in
the three paragraphs prior to the one you have quoted.

If you have a problem with that please raise it in the context of RFC 7981
– not in the context of this draft.

...

237       used is undefined.

 [Les:] As with node MSD, it does not matter. What matters is that you have
duplicate advertisements for the same link and MSD type.

[Les:] The issue is not interoperability but that you do not know which one
is correct. So no matter which one you choose you might use a value that is
either not supported by the advertising node or limits label imposition
unnecessarily.

For the application in this document, I agree that there is really not an
interoperability issue.  I will leave it up to you if you want to add any
text to (potentially) avoid related questions in the future — or we can
wait for the questions, either way is fine with me.

..

...

260       Base MPLS Imposition MSD (BMI-MSD) signals the total number of
MPLS

265       advertising node does not support advertisement of this
capability.

[Les:] This section is not specific to link advertisements or node
advertisements. It is talking about what it means when there is no
applicable advertisement of BMI-MSD.

I think that the confusing part is that text says that the BMI-MSD is "the
total number of MPLS labels **a node** is capable of imposing” — emphasis
on node.  Note that the definitions in §1.1 (Terminology) are not specific
to links or nodes.  For example, the BMI is defined as "the number of MPLS
labels which can be imposed”, with no specific reference to nodes or
links…and the MSD as "the number of SIDs a node or a link on a node”….
Suggestion:

NEW>

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed in a node or link, including all
   service/transport/special labels.

...

[Les:] Guidance for Designated Experts – at least for IS-IS codepoints –
has been defined in RFC 7170. Would it be sufficient to refer to that
document and state that it applies in this case as well??

(I sure hope so. J )

rfc7370 provides guidance that "applies specifically to the "IS-IS TLV
Codepoints” registry”, and it focuses on early allocation.  Even though the
guidance is general... :-(

My intent with asking for guidance was mostly to get you to think about any
specific things that a DE should consider for MSD types.

If there is nothing specific, then I just have one suggestion for the text
you added in -14:

OLD>

Guidance for the Designated Experts is as defined in [RFC7370
<https://tools.ietf.org/html/rfc7370>]

NEW>

General guidance for Designated Experts is provided in [RFC7370
<https://tools.ietf.org/html/rfc7370>].

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 29 Aug 2018 09:56:27 -0700

On August 20, 2018 at 2:15:32 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

Les:

Hi!

V14 of the draft has been posted addressing your comments – subject to my
responses previously sent.

Please let us know if this is sufficient or you still have concerns which
need to be addressed.

I just have one outstanding comment (below).

I think that this comment, along with the ones in my other message on this
thread can be addressed while we move the document forward.  I will start
the IETF Last Call.

Thanks!!

Alvaro.

...

[major] After reading this section, I still don't know how to use the
advertisements.  What should a receiver do with the values?  Maybe the use
is constrained to a controller...maybe the exact operation is out of the
scope of this document.  Either way, please say something.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Aug 2018 23:49:51 +0000

Alvaro –

I have posted V15 addressing your comments.
Responses inline.

From: Alvaro Retana <[email-masked]>
Sent: Wednesday, August 29, 2018 9:54 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]; Christian Hopps <[email-masked]>; [email-masked]
Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13

On August 15, 2018 at 6:51:39 PM, Les Ginsberg (ginsberg) ([email-masked]<mailto:[email-masked]>) wrote:

Les:

Hi!

You and I had an off-line conversation about the topic of multiple advertisements.  I’m replying with similar comments to close the loop with everyone else.

Thanks!

Alvaro.

...
...

...

For the application in this document, I agree that there is really not an interoperability issue.  I will leave it up to you if you want to add any text to (potentially) avoid related questions in the future — or we can wait for the questions, either way is fine with me.

[Les:] I added some text.

..
...

I think that the confusing part is that text says that the BMI-MSD is "the total number of MPLS labels **a node** is capable of imposing” — emphasis on node.  Note that the definitions in §1.1 (Terminology) are not specific to links or nodes.  For example, the BMI is defined as "the number of MPLS labels which can be imposed”, with no specific reference to nodes or links…and the MSD as "the number of SIDs a node or a link on a node”…. Suggestion:

NEW>

[Les:] I modified the definition to be the same as in Section 1.1.

...

rfc7370 provides guidance that "applies specifically to the "IS-IS TLV Codepoints” registry”, and it focuses on early allocation.  Even though the guidance is general... :-(

My intent with asking for guidance was mostly to get you to think about any specific things that a DE should consider for MSD types.

If there is nothing specific, then I just have one suggestion for the text you added in -14:

OLD>

Guidance for the Designated Experts is as defined in [RFC7370<https://tools.ietf.org/html/rfc7370>]

NEW>

General guidance for Designated Experts is provided in [RFC7370<https://tools.ietf.org/html/rfc7370>].

[Les:] Done.

Thanx.

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Aug 2018 23:52:46 +0000

Alvaro –

Inline.

Sent: Wednesday, August 29, 2018 9:56 AM

On August 20, 2018 at 2:15:32 PM, Les Ginsberg (ginsberg) ([email-masked]<mailto:[email-masked]>) wrote:

Les:

Hi!

I think that this comment, along with the ones in my other message on this thread can be addressed while we move the document forward.  I will start the IETF Last Call.

Thanks!!

Alvaro.

...
239     4.  Using Node and Link MSD Advertisements
[major] After reading this section, I still don't know how to use the advertisements.  What should a receiver do with the values?  Maybe the use is constrained to a controller...maybe the exact operation is out of the scope of this document.  Either way, please say something.
[Les:] The proper use of an MSD type is specific to the type. What this section is discussing is not how to use a particular MSD type – or even MSD types in general – but rather the relationship between Node/Link Advertisements what procedures should be followed when one or both are present.
I changed the title of the section to “Procedures for using Node and Link MSD Advertisements”.
   Les

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 30 Aug 2018 09:14:13 -0700

Thanks!

On August 29, 2018 at 7:49:53 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

Alvaro –

Responses inline.

*From:* Alvaro Retana <[email-masked]>
*Sent:* Wednesday, August 29, 2018 9:54 AM
*To:* Les Ginsberg (ginsberg) <[email-masked]>;
[email-masked]
*Cc:* [email-masked]; Christian Hopps <[email-masked]>; [email-masked]
*Subject:* RE: AD Review of draft-ietf-isis-segment-routing-msd-13

Les:

Hi!

Thanks!

Alvaro.

...

...

193       apply.

   is undefined.

...

237       used is undefined.

*[Les:] I added some text.*

..

...

NEW>

*[Les:] I modified the definition to be the same as in Section 1.1.*

...

(I sure hope so. J )

OLD>

NEW>

*[Les:] Done.*

*Thanx.*

*   Les*