Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt

[Lou Berger <[e-mail]>]

Fei,
	I still don't understand the point you're trying to address (in your
proposed language).  Given that you said that you can live with the
published text, shall we just not worry about this?  If not, can you
rephrase the issue in the current text that you'd like to address?

Thanks,
Lou

On 8/16/2012 2:06 AM, [e-mail] wrote:
> 
> Lou
> 
> Thank you for your clarification, see response in line with <fei>
> 
> Regards
> 
> Fei
> 
> 
> *Lou Berger <[e-mail]>*
> 
> 2012-08-16 00:22
> 
> 	
> 收件人
> 	[e-mail]
> 抄送
> 	[e-mail]
> 主题
> 	Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> Fei,
>                 See below.
> 
> On 8/14/2012 11:10 PM, [e-mail] wrote:
>>
>> Hi Lou
>>
>> I can see there are some minor changes when taking a look at the updated
>> new version, and want to check with you the intention of listed two
>> revisions.
>>
>> 1. Section 3 No-GMPLS Recovery Usage
>>
>> The sentence "Note that there are times when no matching state is found,
>> e.g., when processing an initial LSP or when the ASSOCIATION object
>> contains
>> otherwise useful information, and such cases do not alter the processing
>> defined below." is deleted in the version 04, which indicates that the
>> ASSOCIATION object
>> can not be used in a single session whith any kinds of Association Types
>> or the usage in a single session can be defined as an association type
>> specific rules?
> 
> Not sure exactly what you're asking, but this change was editorial in
> nature only, as processing behavior continues to be specified (see the
> 2nd to last paragraph in Section 3.1.2 and 3.2.2.)
> 
> <fei> I want to check whether the ASSOCIATION object is allowed to be
> used in a signal session,
> and find the corresponding description in section 3.1 and 3.2
> "The use of an ASSOCIATION object in a single session is not precluded"
> " Note, the use of an ASSOCIATION object in a single session is not
> precluded"
> No problem now, thanks.
> 
> 
>>
>> 2. The descriptions about Global Association Source in Section 4.1.
>>  IPv4 and IPv6 Extended ASSOCIATION Object Format
>>
>> Similarly, the sentence "It is expected that the global identifier will
>> be derived from the globally unique ASN of the autonomous system hosting
>> the Association Source." does not appear in the new version. The
>> question here is whether the Global Association Source SHOULD host the
>> Association Source or not?  If yeah, it had better being described in
>> the document.
> 
> So the old text was informative only (and was taken from RFC6370).  The
> new text is normative and says use definition from [RFC6370]. So I'm not
> sure what is ambiguous in the new text.  What specific change would you
> like to see?
> 
> <fei> IMHO, the Global Associaiton Source should be the Global_ID that
> hosting
> Association Source, how about "the Global_ID as defined in [RFC6370]that
> hosting
> the Association Source SHALL be used"? Of course, the current
> description is
> correct and includes this possibility.
> 
> 
> Lou
> 
>>
>>
>> Best regards
>>
>> Fei
>>
>>
>> *Lou Berger <[e-mail]>*
>> 发件人:  [e-mail]
>>
>> 2012-08-14 22:10
>>
>>                  
>> 收件人
>>                  [e-mail]
>> 抄送
>>                  
>> 主题
>>                  Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt
>>
>>
>>                  
>>
>>
>>
>>
>>
>>
>> The authors believe that this revision addresses the comments raised by
>> Adrian and discussed on the list. (It also includes few other editorial
>> nits identified by the authors.)
>>
>> Please note, as discussed, there has been one substantive technical
>> change (MUST --> SHOULD):
>>
>>  3.2.1. Resv Message Format
>> OLD
>>  Relative ordering of ASSOCIATION objects of the same type
>>  MUST be preserved by transit nodes.
>> NEW
>>  Relative ordering of ASSOCIATION objects of the same type
>>  *SHOULD* be preserved by transit nodes.
>>
>> Lou (and co-authors)
>>
>> On 8/14/2012 9:45 AM, [e-mail] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>>  This draft is a work item of the Common Control and Measurement Plane
>> Working Group of the IETF.
>>>
>>>                  Title           : RSVP Association Object Extensions
>>>                  Author(s)       : Lou Berger
>>>                           Francois Le Faucheur
>>>                           Ashok Narayanan
>>>                  Filename        : draft-ietf-ccamp-assoc-ext-04.txt
>>>                  Pages           : 16
>>>                  Date            : 2012-08-14
>>>
>>> Abstract:
>>>    The RSVP ASSOCIATION object was defined in the context of GMPLS
>>>    (Generalized Multi-Protocol Label Switching) controlled label
>>>    switched paths (LSPs).  In this context, the object is used to
>>>    associate recovery LSPs with the LSP they are protecting.  This
>>>    object also has broader applicability as a mechanism to associate
>>>    RSVP state, and this document defines how the ASSOCIATION object
>>>    can be more generally applied.  This document also defines
>>>    Extended ASSOCIATION objects which, in particular, can be used in
>>>    the context of the Transport Profile of Multiprotocol Label
>>>    Switching (MPLS-TP).  This document updates RFC 2205, RFC 3209,
>>>    and RFC 3473. It also modifies the definition of the Association
>>>    ID field defined in RFC 4872.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-04
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-04
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
> 
>