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

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

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

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

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

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

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

> >> 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), ..."

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

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

> >>>> 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 ;-)
>
> >
> >>               HOST                              ROUTER
> >>
> >>  _____________________________       ____________________________
> >> |  _______                    |     |                            |
> >> | |       |   _______         |     |            _______         |
> >> | |Appli- |  |       |        |RSVP |           |       |        |
> >> | | cation|  | RSVP <---------------------------> RSVP
> <---------->
> >> | |       <-->       |        |     | _______   |       |        |
> >> | |       |  |process|  _____ |     ||Routing|  |process|  _____ |
> >> | |_._____|  |       -->Polcy||     ||       <-->       -->Polcy||
> >> |   |        |__.__._| |Cntrl||     ||process|  |__.__._| |Cntrl||
> >> |   |data       |  |   |_____||     ||__.____|     |  |   |_____||
> >> |===|===========|==|==========|     |===|==========|==|==========|
> >> |   |   --------|  |    _____ |     |   |  --------|  |    _____ |
> >> |   |  |        |  ---->Admis||     |   |  |       |  ---->Admis||
> >> |  _V__V_    ___V____  |Cntrl||     |  _V__V_    __V_____ |Cntrl||
> >> | |      |  |        | |_____||     | |      |  |        ||_____||
> >> | |Class-|  | Packet |        |     | |Class-|  | Packet |       |
> >> | | ifier|==>Schedulr|================>
> ifier|==>Schedulr|===========>
> >> | |______|  |________|        |data | |______|  |________|
>       |data
> >> |                             |     |                            |
> >> |_____________________________|     |____________________________|
> >>
> >>
> >>                   Figure 1: RSVP in Hosts and Routers
> >>
> >>    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").

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


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

> >>>> 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.
> >> Lou
> >>
> >>>>
> >>>>
> >>>> -----
> >>>> Homepage:
> >>>> <http://belllabs.be/people/dpapadimitriou/>
> >>>> <http://psg.com/~dpapadimitriou>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>