Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

Lou,

Concerning the remark

"Now that said, it really should have been done along with the original object definition."

it is in RFC 4872, but it deals with LSP admission failure (because "type-specific"), as you cover a larger scope I just ask why it is not extended. Text extracted from RFC 4872:

  4) Error Code/Sub-code values

   The following Error code/sub-code values are defined in this
   document:

   Error Code = 01: "Admission Control Failure" (see [RFC2205])

   o "Admission Control Failure/LSP Admission Failure" (4)
   o "Admission Control Failure/Bad Association Type" (5)

Thanks,
-d.
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Wednesday, September 05, 2012 23:31
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04
>
> See below.
>
> On 9/5/2012 4:50 PM, Papadimitriou, Dimitri (Dimitri) wrote:
> >
> > Lou,
> >
> >> -----Original Message-----
> >> From: Lou Berger [mailto:[e-mail]]
> >> Sent: Wednesday, September 05, 2012 19:15
> >> To: Papadimitriou, Dimitri (Dimitri)
> >> Cc: [e-mail];
> >> [e-mail]; [e-mail]
> >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04
> >>
> >> Dimitri (BTW sorry about the dropping the t in my last message)
> >>
> >>       See below.
> >>
> >> On 9/5/2012 12:08 PM, Papadimitriou, Dimitri (Dimitri) wrote:
> >>> Hi Lou,
> >>>
> >>>> -----Original Message-----
> >>>> From: Lou Berger [mailto:[e-mail]]
> >>>> Sent: Wednesday, September 05, 2012 14:36
> >>>> To: Papadimitriou, Dimitri (Dimitri)
> >>>> Cc: [e-mail];
> >>>> [e-mail]; [e-mail]
> >>>> Subject: Re: [RTG-DIR] FW: Review of
> draft-ietf-ccamp-assoc-ext-04
> >>>>
> >>>> Hi Dimiri,
> >>>>       Responses in line...
> >>>>
> >>>> On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri)
> wrote:>  Lou,
> >>>>>
> >>>>> see below,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail]
> >>>>>> [mailto:[e-mail]] On Behalf Of Lou Berger
> >>>>>> Sent: Tuesday, September 04, 2012 23:54
> >>>>>> To: Papadimitriou, Dimitri (Dimitri)
> >>>>>> Cc: [e-mail];
> >>>>>> [e-mail]; [e-mail]
> >>>>>> Subject: Re: [RTG-DIR] FW: Review of
> >> draft-ietf-ccamp-assoc-ext-04
> >>>>>>
> >>>>>> Dimitri,
> >>>>>>       See below.
> >>>>>>
> >>>>>> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote:
> >>>>>>> Hi Lou,
> >>>>>>>
> >>>>>>> See inline:
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Lou Berger [mailto:[e-mail]]
> >>>>>>>> Sent: Tuesday, September 04, 2012 17:25
> >>>>>>>> To: [e-mail]; Papadimitriou, Dimitri (Dimitri)
> >>>>>>>> Cc: [e-mail];
> >>>> [e-mail]
> >>>>>>>> Subject: Re: [RTG-DIR] FW: Review of
> >>>> draft-ietf-ccamp-assoc-ext-04
> >>>>>>>>
> >>>>>>>> Adrian,
> >>>>>>>>       Much Thanks. (BTW is there a reason not to include the
> >>>>>>>> WG in this, or
> >>>>>>>> such, discussions?)
> >>>>>>>>
> >>>>>>>> Dimitri,
> >>>>>>>>       Please see below for inline responses.
> >>>>>>>>
> >>>>>>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote:
> >>>>>>>>> Here is Dimitri's Routing Dir review. Many thanks for
> >>>> the review.
> >>>>>>>>>
> >>>>>>>>> Lou, you can address this and the other comments and post a
> >>>>>>>> new revision.
> >>>>>>>>>
> >>>>>>>>> Adrian
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Papadimitriou, Dimitri (Dimitri)
> >>>>>>>> [mailto:dimitri.papadimitriou@alcatel-
> >>>>>>>>>> lucent.com]
> >>>>>>>>>> Sent: 31 August 2012 13:23
> >>>>>>>>>> To: BRUNGARD, DEBORAH A; [e-mail];
> >>>> [e-mail];
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04
> >>>>>>>>>>
> >>>>>>>>>> Hi All,
> >>>>>>>>>>
> >>>>>>>>>> Here below the review of this document.
> >>>>>>>>>>
> >>>>>>>>>> Technical comments:
> >>>>>>>>>>
> >>>>>>>>>> - Example 3: isn't this extension also not updating
> >> RFC 2205 ?
> >>>>>>>>
> >>>>>>>> Yes. This is stated in the header, abstract and section 3.
> >>>>>>>
> >>>>>>> I thought to include this in the introduction since other
> >>>>>> updated RFC are indicated.
> >>>>>>>
> >>>>>>
> >>>>>> Agreed.  Text has been added.
> >>>>>
> >>>>> OK.
> >>>>>
> >>>>>>>>>> - The statement "In order to support the more general
> >>>>>> usage of the
> >>>>>>>>>> ASSOCIATION object," is actually not correct RFC 4872
> >>>>>>>> doesn't prevent support
> >>>>>>>>> of
> >>>>>>>>>> other usage of the ASSOCIATION object. It has just
> >>>>>>>> documented its usage in the
> >>>>>>>>>> GMPLS recovery context.
> >>>>>>>>
> >>>>>>>> I'm not sure how these two statements (the document text
> >>>>>> and your last
> >>>>>>>> sentence) are mutually inconsistent.  I see no text change
> >>>>>>>> based on this comment.
> >>>>>>>
> >>>>>>> I meant: "In order to document the more general usage of
> >>>>>> the ASSOCIATION object, ..."
> >>>>>>>
> >>>>>>
> >>>>>> While I don't mind the change in this part of the sentience,
> >>>>>> the result
> >>>>>> is a bit odd "In order to document the more general
> usage of the
> >>>>>> ASSOCIATION object, this document ..." So will leave as is.
> >>>>>
> >>>>> "In order to document the more general usage of the ASSOCIATION
> >>>> object, this specification ..."
> >>>>
> >>>> I think we're in the noise here...
> >>>>
> >>>>>>>>>> - Section 3.1, "Cross-session association  based on Path
> >>>>>>>> state is defined in
> >>>>>>>>>> [RFC4872]." the latter defines cross-LSP association
> >>>>>>>> within the same session
> >>>>>>>>> (not
> >>>>>>>>>> cross-session association) but nothing prevents extending
> >>>>>>>> usage to cross-
> >>>>>>>>>> Session.
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>> I see no text change requested based on this comment.
> >>>>>>>
> >>>>>>> I meant: "Cross-LSP association based on Path state is
> >> defined in
> >>>>>>> [RFC4872]; here we document cross-session association..."
> >>>>>>
> >>>>>> I'll change two instances of "Cross-session association"
> >>>> to "Cross-LSP
> >>>>>> association".
> >>>>>
> >>>>> OK.
> >>>>>
> >>>>>>>>>> - Section 3.1.2 the statement "the definition SHOULD allow
> >>>>>>>> for association
> >>>>>>>>> based
> >>>>>>>>>> on identical ASSOCIATION objects" is not clear, does it
> >>>>>>>> that the information
> >>>>>>>>>> elements part of the object shall be identical ?
> >>>>>>>>
> >>>>>>>> I see no difference between the current text (object
> >>>>>> equivalence) and
> >>>>>>>> object information element equivalence.  I don't believe
> >>>>>>>> there's a case
> >>>>>>>> where you can have one without the other.  Please
> >>>> correct me if you
> >>>>>>>> think I'm mistaken.
> >>>>>>>
> >>>>>>> If the association ID are defined such that:
> >>>>>>>
> >>>>>>> - the Association ID of Session 1 or LSP 1 points to the
> >>>>>> Session ID or LSP ID of LSP 2
> >>>>>>>
> >>>>>>> - the Association ID of Session 2 or LSP 2 points to the
> >>>>>> Session ID or LSP ID of LSP 1
> >>>>>>
> >>>>>> Association based on matching Association ID to Session ID
> >>>> is not part
> >>>>>> of this draft.
> >>>>>
> >>>>> if the session ID isn't used - which is possible -
> >>>> documenting the ID
> >>>>> setting to ensure unicity (per association) is to be
> >> documented the
> >>>>> definition only states concerning value setting
> >>>>>
> >>>>> "A value assigned by the the node that originated the
> association.
> >>>>>       When combined with the other fields carried in the
> >>>> object, this
> >>>>>       value uniquely identifies an association."
> >>>>
> >>>> Actually, the document provides additional guidance in the
> >> procedures
> >>>> section:
> >>>>
> >>>>     The Association ID field MUST be set to a value that uniquely
> >>>>     identifies the sessions to be associated within the
> >> context of the
> >>>>     Association Source field.  The Association Source
> field MUST be
> >>>>     set to a unique address assigned to the node originating the
> >>>>     association.
> >>>
> >>> The initial statement should be part of the definition in the form
> >>>
> >>> "The Association ID value space is unique per ?" I write
> >> "?" because is it per node, per RSVP process, per
> Association source ?
> >
> >
> > what about the above one concerning the unicity ?
>
> unique as scoped by the Association Source field. As stated:
>
>       When combined with the other fields carried in the object, this
>       value uniquely identifies an association.
>
> and
>    The Association ID field MUST be set to a value that
>    uniquely identifies the sessions to be associated within
> the context
>    of the Association Source field.  The Association Source field MUST
>    be set to a unique address assigned to the node originating the
>    association.
>
> I think this is sufficiently unambiguous to ensure interoperable
> implementations.
>
> >
> >
> >>> The processing should in my opinion state (or equivalent):
> >>>
> >>> "The Association ID field MUST be set to a unique value
> >> that uniquely
> >>>  identifies the association between sessions that are
> >> associated within
> >>>  the context of the Association Source field."
> >>
> >> I frankly don't see any difference in the wording.
> >
> >
> > "uniquely identify the sessions to be associated"
> >
> > vs
> >
> > "uniquely identify the association"
> >
> > is clearly different.
>
> The association of what? --> Sessions.
>
> So I'm at a loss to see the difference.
>
> In the interest of moving forward I'll use "association being
> identified" (in 3 places.)
>
> >
> >
> >>>>>>> Other elements aren't necessarily identical.
> >>>>>>
> >>>>>> They must be identical in the context of this draft and
> >>>> the absence of
> >>>>>> type-specific processing rules.
> >>>>>>
> >>>>>>> The setting of the association source is application type
> >>>> specific.
> >>>>>>
> >>>>>> Even if true, I don't see how this impacts the text of
> the draft.
> >>>>>
> >>>>> Because a full match (incl.association source) wouldn't apply
> >>>>> anymore. I think the point goes to the question does extension
> >>>>> include association between sessions that uses two
> >> different source
> >>>>> addresses that can be two interface address ?
> >>>>
> >>>> sure. As documented, there is no mention of other fields
> >> to check as
> >>>> part of association identification.
> >>>
> >>> I don't get it. If the matching operation implies that all fields
> >>> shall be identical including the association source how do you
> >>> proceed ?
> >>
> >> Simple.  If the objects are identical, there's an association
> >> identified.  If not, there's no association.
> >
> >
> > This is not the question. If the association are set per source
> > interface how this mechanism shall be used ?
>
> Huh, where is this stated or even implied in the document.
> It only says:
>
>   The Association Source field MUST be set to a unique address
>   assigned to the node originating the association.
>
> This can be any address associated with any node. E.g., a loop back or
> even management station address.
>
>
> > The point I am raising
> > here is this precluded by design and it is a common case
> which likely
> > to happen with the examples you have highlighted in the
> > introduction.
>
> You're right.  If the implementation uses different
> association sources
> to try to identify a single association it won't work.  But
> this is just
> a broken implementation.  The document already repeats the concept of
> using the same address / object contents in so many places I
> don't think
> it needs to be stated yet again.
>
> I'll submit the changes we have so far, and if you still
> think there's a
> need for a text change, please propose it as I'm at a loss.
>
> >
> >
> >>>>>>> Another case (if I am correctly understanding the related
> >>>> text), is
> >>>>>>> related to the MPLS-TP section. The association object of two
> >>>>>>> non-associated session can have the value fields in the
> >>>>>>> ext.association object.
> >>>>>>
> >>>>>> This is a true statement, but unless the contents of the
> >>>> whole object
> >>>>>> are identical, there's no association.
> >>>>>
> >>>>> In GMPLS you will have association source setting being
> >>>> identical for
> >>>>> many tunnels/LSPs (many controllers will set their local
> >> IP address
> >>>>> as source) while actually these LSPs aren't. I don't
> >> think there is
> >>>>> any indication that prevents this to happen ?
> >>>>
> >>>> Correct and this is intentional. All that is required for
> >>>> association is
> >>>> a simple match of objects.  If two nodes use the same
> >> source address
> >>>> without coordinating IDs there may be collisions, but there's
> >>>> no way to
> >>>> know if this is intentional or an error when processing
> >> the path/resv
> >>>> messages.
> >>>
> >>> OK. As such this corroborates my initial remark where the
> >> association
> >>> object was actually the most suited place to put this information.
> >>
> >> Great.  (I think.)
> >
> >
> > I meant was *not* (sorry for the confusion).
> >
> >
> >>>>>>>>>> - Section 3.1.2 "The Association ID field MUST be set to a
> >>>>>>>> value that uniquely
> >>>>>>>>>> identifies the sessions to be associated within the
> >>>>>>>> context of the Association
> >>>>>>>>>> Source field."
> >>>>>>>>>>   this statement is not compatible with e.g. RFC 4873 and
> >>>>>>>> 4872 where
> >>>>>>>>> Association
> >>>>>>>>>> ID are set to LSP ID and not sessions while it is
> >>>> stated in 3.1 "
> >>>>>>>>
> >>>>>>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage"
> >>>>>>>
> >>>>>>> Yes and section 3.1.2 indicates "These procedures
> >>>>>>>    apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
> >>>>>> session state."
> >>>>>>>
> >>>>>>> don't you think this induces confusion ?
> >>>>>>
> >>>>>> Perhaps, but this is why the 3.1 states:
> >>>>>>   This section does not modify processing required to support
> >>>>>> [RFC4872]
> >>>>>>   and [RFC4873].  I'll repeat the sentence at the
> start of 3.1.2.
> >>>>>
> >>>>> This being said the Code point for RFC 4873 isn't changed
> >> but points
> >>>>> to this document. Any reason since there is no
> processing change ?
> >>>>
> >>>> I assume you're referring to the Resource Sharing type.  This
> >>>> is updated as the same type is now usable for non-recovery LSPs.
> >>>
> >>> OK.
> >>>
> >>>>>>>> so it does not impact to RFC 4873 and 4872
> >>>>>> implementations.  As stated
> >>>>>>>> in the draft and quoted by you:
> >>>>>>>>
> >>>>>>>>> This section
> >>>>>>>>> does not
> >>>>>>>>>> modify processing required to support [RFC4872] and
> >>>>>>>> [RFC4873], and which is
> >>>>>>>>>> reviewed in Section 3 of [RFC6689]. "
> >>>>>>>
> >>>>>>> The point I am raising is that Section 3.1 reads as there no
> >>>>>>> "additions" whereas once reaching Section 3.1.2 one
> >>>> understands that
> >>>>>>> the statement no modifications meant actually extensions.
> >>>>>>>
> >>>>>>> Section 3.1 states "This section does not modify processing
> >>>>>> required to
> >>>>>>>    support [RFC4872] and [RFC4873], and which is reviewed
> >>>>>> in Section 3
> >>>>>>>    of [RFC6689]. "
> >>>>>>>
> >>>>>>> Section 3.1.2 states " These procedures
> >>>>>>>    apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
> >>>>>> session state."
> >>>>>>>
> >>>>>>> Hence,
> >>>>>>>
> >>>>>>> Section 3.1.2 should be rephrased as
> >>>>>>>
> >>>>>>>    "This section is based on the processing rules described
> >>>>>> in [RFC4872]
> >>>>>>>    and [RFC4873], and which is reviewed in [RFC6689].
> >>>>>> These procedures
> >>>>>>>    apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
> >>>>>> session state."
> >>>>>>>
> >>>>>>> Section 3.1.2 should be rephrased as
> >>>>>>>
> >>>>>>>    "This section generalizes the processing rules described
> >>>>>> in [RFC4872]
> >>>>>>>    and [RFC4873], and which is reviewed in [RFC6689], for
> >>>>>> application
> >>>>>>>    to MPLS LSPs and non-LSP session state. For GMPLS
> >> LSP rules are
> >>>>>>>    extended for applications not related to the recovery
> >>>>>> and resource
> >>>>>>>    sharing."
> >>>>>>
> >>>>>> I've revised the text to read:
> >>>>>>
> >>>>>>     This section is based on, and extends, the processing rules
> >>>>>>     described in [RFC4872] and [RFC4873], and which is
> >> reviewed in
> >>>>>>     [RFC6689].  This section applies equally to GMPLS
> >>>> LSPs, MPLS LSPs
> >>>>>>     and non-LSP session state.  Note, as previously
> stated, this
> >>>>>>     section does not modify processing required to support
> >>>> [RFC4872]
> >>>>>>     and [RFC4873].
> >>>>>
> >>>>> OK.
> >>>>>
> >>>>>>>> 2) I also think "not compatible" is an overstatement, but
> >>>>>> I guess that
> >>>>>>>> it isn't really a critical point to discuss as the
> >>>> referenced text
> >>>>>>>> doesn't relate to [RFC4872] and [RFC4873].
> >>>>>>>
> >>>>>>> The proposed phrasing would resolve it.
> >>>>>>>
> >>>>>>>>>> and in RFC 4873/Section 3.2 "The
> >>>>>>>>>> ASSOCIATION object is used to associate different LSPs
> >>>>>>>> with each other."
> >>>>>>>>
> >>>>>>>> I see no text change requested based on this comment.
> >>>>>>>
> >>>>>>> Ditto.
> >>>>>>>
> >>>>>>>>>> - Section 3.1.2 "An association is deemed to exist when
> >>>>>>>> the same values are
> >>>>>>>>>> carried in all fields of the ASSOCIATION objects being
> >>>>>>>> compared." this
> >>>>>>>>> introduces
> >>>>>>>>>> an additional level of indirection. To associate A to B A
> >>>>>>>> can simply refer to
> >>>>>>>>> an
> >>>>>>>>>> identifier of B (and vice versa), A doesn't need to have
> >>>>>>>> an additional ID
> >>>>>>>>> (e.g. C)
> >>>>>>>>>> that is also associated to B. Generalization would consist
> >>>>>>>> here in introducing
> >>>>>>>>> an
> >>>>>>>>>> ext.association ID common to A, B, and C. In other terms,
> >>>>>>>> generalizing the
> >>>>>>>>> notion
> >>>>>>>>>> of association doesn't require the introduction of an
> >>>>>>>> additional level of
> >>>>>>>>>> indirection.
> >>>>>>>>
> >>>>>>>> I really have no idea what this comment means.  There is no
> >>>>>>>> indirection stated or implied by the text.
> >>>>>>>
> >>>>>>> It is the result of what the text implies and it is
> specifically
> >>>>>>> related to the "Association ID". Implicitly the
> >> document mandates
> >>>>>>> than this identifier can't take any value of existing fields
> >>>>>>> identifying tunnels/LSPs.
> >>>>>>
> >>>>>> Not at all.  As long as the IDs as consistently set across
> >>>> association
> >>>>>> objects, an association will be made.  Furthermore,
> type specific
> >>>>>> processing can be defined that allows implicit mapping
> >> such as you
> >>>>>> defined in 4872.
> >>>>>
> >>>>> The first item to check is the Association Type to distinguish
> >>>>> between matching processes. The statement "In the absence of
> >>>>> Association Type-specific rules for identifying
> >> association,.." was
> >>>>> probably intended to state (to remove the confusion of
> >> the statement
> >>>>> "identifying assocation"):
> >>>>>
> >>>>> "If the ASSOCIATION type does not refer to Association
> >> Type-specific
> >>>>> rules for the processing of the ASSOCIATION object (in
> >>>> which case the
> >>>>> Association Type-specific rules SHALL be applied), ..."
> >>>>
> >>>> IMO this should be left to the definition of the Association
> >>>> Type-specific rules, i.e., is beyond the scope of this document.
> >>>
> >>> OK.
> >>>
> >>>>>>>>  It means test for simple equivalence,
> >>>>>>>> i.e., (ASSOCIATION object of A) = (ASSOCIATION object of
> >>>>>> B) and that's
> >>>>>>>> it. There's no (session) ID referencing.  Can you restate
> >>>>>>>> your concern?
> >>>>>>>
> >>>>>>> My concern is this an equivalence between objects not an
> >>>>>> assocation of sessions.
> >>>>>>>
> >>>>>>
> >>>>>> Per this document, equivalence between objects identifies an
> >>>>>> assocation
> >>>>>> of sessions.  This document does not generalize the
> session ID to
> >>>>>> association ID matching that was part of 4872.
> >>>>>
> >>>>> The above text would clarify the point.
> >>>>
> >>>> The following has been added to the second to last paragraph
> >>>> of Section 1.
> >>>>
> >>>>     When using the procedures defined below, association
> >> is identified
> >>>>     based on simple ASSOCIATION object matching.  Some
> of the other
> >>>>     matching mechanisms defined in RFC 4872, e.g.,
> >> matching based on
> >>>>     Session IDs, are not generalized.
> >>>
> >>> I would write:
> >>>
> >>>       When using the procedures defined in this document,
> >> association is identified
> >>>       based on ASSOCIATION object matching.  Some of the other
> >>>       matching mechanisms defined in RFC 4872, e.g.,
> >> matching based on
> >>>       Session IDs, are not generalized in this document.
> Association
> >>>       type-specific processing is outside the scope of this
> >> document.
> >>>
> >>
> >> understood, I'll modify the paragraph. (subject to style
> differences.)
> >>
> >>>>>>>>>> - Section 3.2.2 I understand triggers for Resv-initiated
> >>>>>>>> associations aren't
> >>>>>>>>>> documented but how to prevent a sender willing to demote
> >>>>>>>> receiver-driven
> >>>>>>>>>> associations ?
> >>>>>>>>
> >>>>>>>> Can you clarify this question?
> >>>>>>>
> >>>>>>> Let me put first in context. Generalization includes
> Rcv driven
> >>>>>>> associations but only additions are documented.
> >>>>>>>
> >>>>>>>> Are you asking:
> >>>>>>>> - how a Path sender can prevent a receiver initiated
> >>>>>> association? (it
> >>>>>>>> can't)
> >>>>>>>>
> >>>>>>>> - how a Resv sender removes an association? (it just removes
> >>>>>>>> the object, no different from a path message)
> >>>>>>>
> >>>>>>> The corresponding processing is to be documented.
> >> Because one can
> >>>>>>> also demote an association by having each LSP/session
> >> pointing to
> >>>>>>> itself while keeping the object in the Path/Resv message.
> >>>>>>
> >>>>>> This sounds like the implicit matching rules in 4872.
> >>>> Such session ID
> >>>>>> to association ID matching is not part of this document.
> >>>>>
> >>>>> I hear you but as the ASSOCIATION ID value setting
> >> doesn't state it
> >>>>> can't be done, you can get the same result.
> >>>>
> >>>> Sure, and this would be perfectly fine way for an
> implementation to
> >>>> select its IDs for certain possible applications, but this
> >> is a local
> >>>> implementation choice in the general case, or
> >> type-specific processing
> >>>> which is outside the scope of this document.
> >>>
> >>> OK.
> >>>
> >>>>> You could even assume that changing ID to an unused but
> >> value would
> >>>>> lead to the same result (as matching wouldn't give a
> >> positive result
> >>>>> the ASSOCIATION would also be removed since it can't be found
> >>>>> anymore).
> >>>>
> >>>>
> >>>>>
> >>>>>>>> - something else?
> >>>>>>>>
> >>>>>>>>>> - Section 3.1.2 and 3.2.2 no error processing is being
> >>>> documented
> >>>>>>>>
> >>>>>>>> I think this is a fair point.  The only case I think that
> >>>>>>>> can/should be
> >>>>>>>> addressed is unknown types.  (As is usual, per
> >> RFC2205, errors in
> >>>>>>>> formats to not trigger any specific message response.)
> >>>>>>>> Sections 3.1 and
> >>>>>>>> 3.2 only discuss identification of associations, so I
> >>>>>> propose adding a
> >>>>>>>> section 3.3.2. How about something like:
> >>>>>>>>
> >>>>>>>>   3.3.2. Unknown Association Types
> >>>>>>>>
> >>>>>>>>   A node that receives an ASSOCIATION object with an unknown
> >>>>>>>>   ASSOCIATION type MUST forward all received
> >> ASSOCIATION objects
> >>>>>>>>   as defined above.  The node MAY also identify
> >> associations per
> >>>>>>>>   the defined processing, e.g., to make this information
> >>>> available
> >>>>>>>>   via a management interface.
> >>>>>>>
> >>>>>>> OK. Wouldn't you document PathErr/ResvErr and Notify ?
> >>>>>>
> >>>>>> IMO Not for an unknown type.
> >>>>>
> >>>>> I don't understand the answer.
> >>>>
> >>>> I don't think unknown type should result in a
> PathErr/ResvErr at a
> >>>> transit/egress/ingress node.
> >>>
> >>> The question why do you use "unknown" type and not
> >>>
> >>> Error Code = 01: "Admission Control Failure" (see [RFC2205])
> >>>
> >>>    o "Admission Control Failure/Session Admission Failure" (6)
> >>
> >> Because I don't think lack of support of a type should result in an
> >> error in the general case. (for example would you generate
> an error on
> >> transit nodes for associations that are only relevant to
> >> end-points, or vice versa?)
> >
> >
> > How would you then allow that session to cross the network ? Thus it
> > depends on policy on what operator wants to apply at ingress (not up
> > to the protocol to decide/enforce a policy).
>
> So what you're really asking for is a compatibility section that says
> how to deal with the case with inconsistent support of an association
> type. Well, sure we can add something.  Now that said, it
> really should
> have been done along with the original object definition.
>
> >
> >
> >>>>>>>>>> whereas mis-
> >>>>>>>>>> match in association should be considered as a
> generic error.
> >>>>>>>>
> >>>>>>>> This isn't a detectable error case as it is impossible for
> >>>>>> a node to
> >>>>>>>> know if two association objects are intentionally or
> >>>>>> unintentionally
> >>>>>>>> different.
> >>>>>>>
> >>>>>>> Earlier, in the text it is mentioned that processing
> >>>>>> implies checking
> >>>>>>> all Path/Resv state. We have to understand that putting
> >> in place a
> >>>>>>> generic processing (outside a specific ASSOCIATION
> Type) renders
> >>>>>>
> >>>>>> I think this sentence got truncated...
> >>>>>
> >>>>> ... safeguard rule advisable.
> >>>>>
> >>>>>>>>>> - Section 3.3 states "Since the admission control function
> >>>>>>>> is outside the
> >>>>>>>>> scope of
> >>>>>>>>>> RSVP,..." are you sure ?
> >>>>>>>>
> >>>>>>>> Yes.  Per RFC2205:
> >>>>>>>
> >>>>>>> Yes I know the figuere whose terms mixes functions, protocol
> >>>>>>> processes, etc. but this goes beyond the review of this
> >>>> document ;-)
> >>>>>>
> >>> [snip figure]
> >>>>>>>>    an RSVP QoS request is passed to two local
> >>>>>>>>    decision modules, "admission control" and "policy
> control".
> >>>>>>>>
> >>>>>>>>>> admission control is an intrinsic function associated
> >>>>>>>>> to RFC
> >>>>>>>>>> 2205 (there are errors documented for admission control
> >>>>>>>> failures). I think you
> >>>>>>>>>> mean that the inner working of the mechanisms used by
> >>>>>>>> nodes to determine if
> >>>>>>>>>> they have sufficient available resources to support
> >>>>>>>> incoming requests.
> >>>>>>>>
> >>>>>>>> I think this is the same as what is stated.
> >>>>>>>
> >>>>>>> What you mean is: the inner-working or implementation
> >> of admission
> >>>>>>> control for QoS requests is outside scope of RFC 2205.
> >>>>>>>
> >>>>>>>> we can add "implementation specifics ", i.e., " Since the
> >>>>>>>> implementation
> >>>>>>>> specifics of the admission control function is outside the
> >>>>>>>> scope " if it helps.
> >>>>>>>
> >>>>>>> Yes it does because the term "outside scope" has different
> >>>>>> meanings depending on context.
> >>>>>>>
> >>>>>>
> >>>>>> done.
> >>>>>>
> >>>>>>>>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION
> >>>>>>>> object and the IPv6
> >>>>>>>>>> ASSOCIATION object. As defined, these objects each contain
> >>>>>>>> an Association
> >>>>>>>>>> Source field and a 16-bit Association ID field. The
> >>>>>>>> combination of the
> >>>>>>>>> Association
> >>>>>>>>>> Source and the Association ID uniquely identifies the
> >>>>>>>> association." but in the
> >>>>>>>>>> context RFC 4872 this association is defined in the
> >>>>>>>> context of the same tunnel
> >>>>>>>>>> end-point
> >>>>>>>>
> >>>>>>>> How about we clarify: "*As described above,* the
> >>>>>>>> combination of the Association Source and the Association ID
> >>>>>>>> uniquely identifies the association."
> >>>>>>>
> >>>>>>> It would be better to state
> >>>>>>>
> >>>>>>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
> >>>>>>> ASSOCIATION object in the context of a given session.
> >> As defined,
> >>>>>>> these objects each contain an Association Source field
> >>>> and a 16-bit
> >>>>>>> Association ID field. The combination of the Association
> >>>> Source and
> >>>>>>> the Association ID uniquely identifies the association.
> >>>> This doesn't
> >>>>>>> prevent that Association Types MAY further specify the
> >> context for
> >>>>>>> which this association is defined."
> >>>>>>
> >>>>>> It now reads:
> >>>>>>
> >>>>>>     [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
> >>>>>>     ASSOCIATION object.  As defined, these objects each
> >> contain an
> >>>>>>     Association Source field and a 16-bit Association ID
> >> field.  As
> >>>>>>     described above, the contents of the object uniquely
> >> identifies
> >>>>>>     an association.  Because the Association ID field
> is a 16-bit
> >>>>>>     field, an association source can allocate up to
> >> 65536 different
> >>>>>>     associations and no more.
> >>>>>
> >>>>> OK
> >>>>>
> >>>>>>>>> (and actually the same for RFC 4873 which relies on MBB
> >>>> as defined
> >>>>>>>>> in
> >>>>>>>>>> RFC 3209)
> >>>>>>>>
> >>>>>>>> I don't believe this statement is correct, but again this
> >>>>>> is really a
> >>>>>>>> discussion beyond this draft.
> >>>>>>>
> >>>>>>> The statement here above is also to applicable to RFC 4873.
> >>>>>>>
> >>>>>>>>>> - Section 4: How is the following use case "There are
> >>>>>>>> scenarios where this
> >>>>>>>>> number
> >>>>>>>>>> is insufficient. (For example where the association
> >>>>>>>> identification is best
> >>>>>>>>> known
> >>>>>>>>>> and identified by a fairly centralized entity, which
> >>>>>>>> therefore may be involved
> >>>>>>>>> in a
> >>>>>>>>>> large number of associations.)" related to those proposed
> >>>>>>>> in the introduction.
> >>>>>>>>> ?
> >>>>>>>>
> >>>>>>>> As I read it, it enables practical third party (e.g.,
> >>>>>>>> management entity)
> >>>>>>>> creation and management of association IDs.  But, I'll
> >>>> defer to my
> >>>>>>>> coauthors on this.
> >>>>>>>
> >>>>>>> OK. Please let me know the result(s) of the discussion.
> >>>>>>>
> >>>>>>>>>> - Section 4: I don't question the requirement stated in
> >>>>>>>> "Per [RFC6370],
> >>>>>>>>> MPLS-TP
> >>>>>>>>>> LSPs can be identified based on an operator unique global
> >>>>>>>> identifier.  The
> >>>>>>>>>> [RFC6370] defined "global identifier", or Global_ID, is
> >>>>>>>> based on [RFC5003] and
> >>>>>>>>>> includes the operator's Autonomous System Number (ASN)."
> >>>>>>>> the question is why
> >>>>>>>>>> the information is best encoded as part of the ASSOCIATION
> >>>>>>>> object ? isn't this
> >>>>>>>>> an
> >>>>>>>>>> LSP ATTRIBUTE or a Session Name ?
> >>>>>>>>
> >>>>>>>> It's the solution the WG agreed to.  Other options are of
> >>>>>>>> course possible.
> >>>>>>>
> >>>>>>> My comment is specific because it triggers the question
> >>>> on how many
> >>>>>>> objects will we end up in spreading identification
> >> information (it
> >>>>>>> would be interesting to document the why this was
> felt the most
> >>>>>>> suited object as it is not a natural choice); more general
> >>>>>> comment is
> >>>>>>> what defines the "acceptable" use/extension of association.
> >>>>>>
> >>>>>> I think the last comment is a reasonable discussion to
> >>>> have.  Not sure
> >>>>>> it belongs in, or gates the discussion.
> >>>>>
> >>>>> The LSP attributes RFC included this info for instance. This has
> >>>>> prevented lots of problems in use of the object because
> >> the content
> >>>>> of most objects could have been added to the LSP
> >> attribute RFC (cf.
> >>>>> Sect.8 "8.  Summary of Attribute Bit Allocation" and Sect.10
> >>>>> "Guidance for Key Application Scenarios").
> >>>>
> >>>> Do you have some suggestions/text in mind?
> >>>
> >>> I will propose a Section for this. Can be done as part of
> >> this e-mail.
> >
> >
> > Can you put a placeholder in the document. Putting the full
> text would make this thread unreadable.
> >
>
> Please send it in a response to the publication notification
> of the next
> version.  Please also include the CCAMP WG as they will need to review
> the text.
>
> >
> >
> >>>>>>>>>> - Section 4.2: states "It is important to note that
> >>>>>>>> Section 4 defines
> >>>>>>>>> association
> >>>>>>>>>> identification  based on ASSOCIATION object matching, and
> >>>>>>>> that such matching
> >>>>>>>>> is
> >>>>>>>>>> based on the comparison of all fields in a ASSOCIATION
> >>>>>>>> object (unless type-
> >>>>>>>>>> specific comparison rules are defined).  This applies
> >>>>>>>> equally to  ASSOCIATION
> >>>>>>>>>> objects and Extended ASSOCIATION objects." any association
> >>>>>>>> is based on a form
> >>>>>>>>>> of matching, point here is that the matching and the
> >>>>>>>> identification of the
> >>>>>>>>> initiation
> >>>>>>>>>> of the matching information are distinct information
> >>>>>>>> entities (difference
> >>>>>>>>> between
> >>>>>>>>>> WHO and WHAT). I suggest to make a clearer distinction and
> >>>>>>>> specify setting and
> >>>>>>>>>> processing accordingly.
> >>>>>>>>
> >>>>>>>> I'm not seeing the issue.  Can you perhaps propose some text?
> >>>>>>>
> >>>>>>> Here is the proposed text
> >>>>>>>
> >>>>>>> "It is important to note that Section 4 defines association
> >>>>>>>  identification  based on ASSOCIATION object matching, and
> >>>>>>>  that such matching is based on the comparison of the fields
> >>>>>>>  as determined by the ASSOCIATION Type of the ASSOCIATION
> >>>>>>>  object. This applies equally to ASSOCIATION objects and
> >>>>>>>  Extended ASSOCIATION objects."
> >>>>>>
> >>>>>> Here's the revised text.
> >>>>>>     Identification of association is not modified by this
> >>>> section.  It
> >>>>>>     is important to note that Section 4 defines association
> >>>>>>     identification based on ASSOCIATION object matching,
> >>>> and that such
> >>>>>>     matching, in the absence of type-specific comparison
> >> rules, is
> >>>>>>     based on the comparison of all fields in an
> >> ASSOCIATION object.
> >>>>>>     This applies equally to ASSOCIATION objects and Extended
> >>>>>>     ASSOCIATION objects.
> >>>>>
> >>>>> I would write (look at the text just above where you state "As
> >>>>> defined, these objects each contain an Association Source
> >>>> field and a
> >>>>> 16-bit Association ID field.  As described above, the
> >>>> contents of the
> >>>>> object uniquely identifies an association." ... there
> is a need to
> >>>>> distinguish between identifying the ASSOCIATION object
> vs matching
> >>>>> ASSOCIATION objects).
> >>>>
> >>>> sure. But you need to be sure you're noting the difference
> >> between the
> >>>> word "association" and the thing "ASSOCIATION object".
> >>>
> >>> I am.
> >>>
> >>>>> This would
> >>>>>
> >>>>> "The procedure to perform ASSOCIATION object matching as
> >> defined in
> >>>>> Section 4 is not modified by this section. It is
> important to note
> >>>>> that Section 4 defines ASSOCIATION object matching if the
> >>>> ASSOCIATION
> >>>>> type does not refer to Association Type-specific rules for the
> >>>>> processing of the ASSOCIATION object (in which case the
> >> Association
> >>>>> Type-specific rules SHALL be applied); otherwise,
> >> ASSOCIATION object
> >>>>> matching applies by comparing all fields in an
> ASSOCIATION object.
> >>>>> This procedure applies equally to ASSOCIATION objects
> and Extended
> >>>>> ASSOCIATION objects."
> >>>>
> >>>> one more time, revised text now reads:
> >>>>     The procedures related to association identification are not
> >>>>     modified by this section.  It is important to note
> >> that Section 4
> >>>>     defines the identification of associations based on
> ASSOCIATION
> >>>>     object matching and that such matching, in the absence of
> >>>>     type-specific comparison rules, is based on the
> >> comparison of all
> >>>>     fields in an ASSOCIATION object.  This applies equally to
> >>>>     ASSOCIATION objects and Extended ASSOCIATION objects.
> >>>
> >>> I would state "in the absence of type-specific comparison
> rules (for
> >>> the Type value of the object being processed), is based on the
> >>> comparison of all fields in an ASSOCIATION object."
> >>>
> >>> because absence of rules is a generic statement.
> >>
> >> Again, I don't see the difference in meaning -- I think
> we're in the
> >> domain of style here.
> >
> >
> > The problem with your statement is: there is no (absence)
> > type-specific rule then apply full matching
> >
> > Mine it is either the one or the other.
>
> This is informative text (at this point).  I also think it
> says the same
> thing.
>
> >
> >
> >>>>>>>>>> - Section 4.2: shouldn't "error processing" being
> >> documented ?
> >>>>>>>>
> >>>>>>>> Here too, I think the only error processing is as
> >>>> discussed above.
> >>>>>>>> Shout if you think otherwise.
> >>>>>>>>
> >>>>>>>>>> Example include
> >>>>>>>>>> admission control where receiving node rejects the
> >>>>>>>> incoming Path msg if the
> >>>>>>>>>> originating Global_ID/Ext.ASSOCIATION object isn't
> included,
> >>>>>>>>
> >>>>>>>> Interesting, but this is a type specific error.  To me this
> >>>>>>>> sounds like
> >>>>>>>> a new admission control error that should be defined as
> >>>> part of the
> >>>>>>>> type-specific definition.
> >>>>>>>
> >>>>>>> Admission control failures are part of the error codes
> >>>>>> defined in RFC 2205.
> >>>>>>
> >>>>>> exactly!
> >>>>>>
> >>>>>>>>>> unauthorized
> >>>>>>>>>> Global ID ?
> >>>>>>>>
> >>>>>>>> Again interesting, but this is a new policy (and policy
> >>>> error) that
> >>>>>>>> wasn't proposed or discussed in the WG.  I think this
> >>>>>> would be a fine
> >>>>>>>> addition, but is beyond the current document discussion. It
> >>>>>>>> could always be added if proposed.
> >>>>>>>
> >>>>>>> I defer this point to the AD.
> >>>>>>
> >>>>>> WFM.
> >>>>>>
> >>>>>>>
> >>>>>>>>>> etc. but also mismatches between Association source
> >> and Global
> >>>>>>>>>> Association source ?
> >>>>>>>>
> >>>>>>>> How would such a thing be detected, by checking BGP state?
> >>>>>> I guess we
> >>>>>>>> could add a new error code, but again I think we're going
> >>>>>> beyond the
> >>>>>>>> intent of the document/WG.
> >>>>>>>
> >>>>>>> Same here.
> >>>>>>>
> >>>>>>>>>> - Section 4.1 and 4.2: the former states "The [RFC6370]
> >>>>>>>> defined global
> >>>>>>>>> identifier,
> >>>>>>>>>> or Global_ID, is based on [RFC5003] and includes the
> >>>>>>>> operator's Autonomous
> >>>>>>>>>> System Number (ASN)." while the latter "the use of the
> >>>>>>>> Global_ID is not
> >>>>>>>>> related
> >>>>>>>>>> to the use of the ASN in protocols such as BGP." which one
> >>>>>>>> applies ?
> >>>>>>>>
> >>>>>>>> I'll drop the note.  This is better aligned with the field
> >>>>>> definition
> >>>>>>>> which has been updated based on comments of other reviewers.
> >>>>>>>>
> >>>>>>>> The current definition is:
> >>>>>>>>
> >>>>>>>>     This field contains a value that is a unique global
> >>>>>> identifier or
> >>>>>>>>     the special value zero (0).  When non-zero and not
> >>>>>> overridden by
> >>>>>>>>     local policy, the Global_ID as defined in [RFC6370]
> >>>>>> SHALL be used.
> >>>>>>>>     The special value of zero indicates that no global
> >>>>>> identifier is
> >>>>>>>>     present. Use of the special value of zero SHOULD be
> >>>> limited to
> >>>>>>>>     entities contained within a single operator.
> >>>>>>>
> >>>>>>> OK
> >>>>>>>
> >>>>>>>>>> - Section 5 Documenting means to prevent/mitigate
> >>>>>>>> mis-association(s) and
> >>>>>>>>>> possible impact on security would be advisable. If this is
> >>>>>>>> felt to be
> >>>>>>>>> "application" or
> >>>>>>>>>> "type" specific a recommendation should be stated that the
> >>>>>>>> security mechanisms
> >>>>>>>>>> have to be documented as part of these documents.
> >>>>>>>>
> >>>>>>>> Why is there any additional risk than what " was
> >>>>>> previously defined in
> >>>>>>>> [RFC4872] and [RFC4873]."? (as is already stated in
> the draft.)
> >>>>>>>
> >>>>>>> I try to prevent that any further use/documents would
> state "no
> >>>>>>> additional risk compared to RFC 4872 and RFC 4873" or
> >>>> equivalent but
> >>>>>>> the application is running for voice calls over the
> >>>>>> Internet which is
> >>>>>>> a totally different application than G/MPLS Recovery/Resource
> >>>>>>> Sharing.
> >>>>>>
> >>>>>> Fair enough, but what additional issues do you foresee
> >>>> that should be
> >>>>>> covered?
> >>>>>
> >>>>> Nodes associating sessions, etc. should have the mean to
> >> verify the
> >>>> initiator of the association.
> >>>>
> >>>> This is true for every object in RSVP!  I have no
> >> objection to object
> >>>> signing, ala SIDR, but this is well beyond the scope of
> >> this document
> >>>> and certainly isn't introduced in this document.
> >>>
> >>> We have to bring this point the Security directorate and
> >> ask them for
> >>> guidance (there could be a short term and a long term approach). I
> >>> understand the corresponding generic mechanism to perform such
> >>> verification isn't to be documented here but it has to be
> mentioned.
> >>> We loose track of all these security holes... hackers don't.
> >>
> >> RSVP's chain of trust is called out in RFC5920, which is
> reference by
> >> this draft.  I certainly have no issue with a general discussion on
> >> RSVP's chain of trust model, but the scope of this conversation is
> >> beyond (and should be scoped) to this draft.
> >
> >
> > Can you point which section of that RFC you are referring
> to that would help the reader.
> >
> > I am asking because I didn't find any that speaks about
> ASSOCIATION object.
>
> Again, the association object is defined in [RFC4872] not
> this document.
>  I'll add a reference to "chain of trust model".
>
> Lou
>
> PS I'll submit the draft in a couple of minutes.
>
> >
> >
> >> Thanks,
> >> Lou
> >>
> >>>
> >>> OK for the rest. We are nearly done.
> >>>
> >>> Thanks,
> >>> -dimitri.
> >>>>>>>>>> Editorials:
> >>>>>>>>>>
> >>>>>>>>>> - Introduction: "This document expands the possible usage
> >>>>>>>> of the ASSOCIATION
> >>>>>>>>>> object to
> >>>>>>>>>>   non-GMPLS and non-recovery contexts." Suggested to state
> >>>>>>>> the actual the
> >>>>>>>>>> scope includes RSVP (instead of what it is not)
> >>>>>>>>
> >>>>>>>> I'll add:
> >>>>>>>>   The expanded usage applies equally to GMPLS LSPs
> >>>> [RFC3473], MPLS
> >>>>>>>>   LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205],
> >> [RFC2207],
> >>>>>>>>   [RFC3175] and [RFC4860].
> >>>>>>>
> >>>>>>> OK.
> >>>>>>>
> >>>>>>>>>> - Introduction: s/different ports/different destination
> >>>>>> (dst) ports
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>> sure.
> >>>>>>>>
> >>>>>>>>>> - Section 2 would better refer to a "Generalization"
> >>>>>> rather than a
> >>>>>>>>> "modification"
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>> I'd be okay with this, but I think modification makes is less
> >>>>>>>> likely to be misinterpreted so will leave as is.
> >>>>>>>
> >>>>>>> The term modification implies a change in existing
> >>>> processing (even
> >>>>>>> if the intention is different) and actually as the
> >>>> applicability is
> >>>>>>> now possible to RSVP and MPLS-TE.
> >>>>>>
> >>>>>> This isn't a major point for me, so will change it. (In
> >> 5 places.)
> >>>>>
> >>>>> OK (actually the doc. generalizes the use of the object
> >> whereas 4873
> >>>> for inst documents type-specific/specialized use of the object)
> >>>>>
> >>>>>>>>>> - Section 3 states "As defined by [RFC4872] and reviewed
> >>>>>>>> in [RFC6689],..." but
> >>>>>>>>> an
> >>>>>>>>>> information RFC doesn't review   at best "documents"
> >>>>>>>> certain usage. This
> >>>>>>>>>> statement is repeated at multiple places.
> >>>>>>>>
> >>>>>>>> Why can't it review?  This is what the abstract of RFC6689
> >>>>>>>> says it does.
> >>>>>>>
> >>>>>>> It was overstated in RFC 6689.
> >>>>>>
> >>>>>> This document doesn't change 6689.
> >>>>>
> >>>>> OK.
> >>>>>
> >>>>>>>>>> - Section 3 mentions "Object usage in both Path and Resv
> >>>>>>>> messages is
> >>>>>>>>> discussed.
> >>>>>>>>>> The usage applies equally to
> >>>>>>>>>>    GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP
> >>>>>>>> RSVP sessions
> >>>>>>>>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having
> >>>>>>>> such statement in the
> >>>>>>>>>> introduction would desirable.
> >>>>>>>>
> >>>>>>>> Fair enough.
> >>>>>>>>
> >>>>>>>> Thank you for the review!
> >>>>>>>
> >>>>>>> OK.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> -d.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Lou
> >>>>>
> >>>>> Thanks,
> >>>>> -d.
> >>>>
> >>>> Thanks again.
> >>>>
> >>>> Lou
> >>>>
> >>>> PS I'll submit a revised version of the draft at some
> >> point today to
> >>>> document all changes to date.
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>