Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Lou,

OK, I am fine if the authors and chairs like the current content organization.

Thanks

Fatai

Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

----- Original Message ----- 
From: "Lou Berger" <lberger@labn.net>
To: "Fatai Zhang" <zhangfatai@huawei.com>
Cc: <ccamp@ietf.org>
Sent: Wednesday, April 13, 2011 9:11 PM
Subject: Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

> Fatai,
> You raise a reasonable question.
> 
> In general, the reason to have separate documents is really about how we
> expect implementations/usage to occur *after* the documents become RFCs.
> In particular, we generally follow the practice that if the functions
> will typically be implemented/required as a set, then the functions
> should be published as a single document; and if the functions are
> completely separable, then they should be published as separate RFCs.
> This is important from a conformance statement perspective (a whole RFC
> is supported, not sections X, Y and Z of and RFC).
> 
> Am important related consideration is avoiding interoperability issues
> seen in the past with subset implementations. In particular, we try
> avoid the case where two implementations that state conformance to the
> same RFC cannot interoperate to provide the same function.
> 
> Of course these are just general principles.
> 
> So if we ask the question will the functions covered in (2) and the
> draft being polled always be implemented as a set.  Given
> draft-ietf-ccamp-rsvp-resource-sharing, I suspect the answer is no.
> 
> Given this perspective, do you still believe that merging the drafts is
> a good idea?
> 
> Lou
> 
> On 4/12/2011 10:02 PM, Fatai Zhang wrote:
>> Hi all,
>>  
>> This draft just introduces a new Association Type, so do we really need
>> one more separate draft for this simple thing?
>>  
>> In Prague meeting, we know that there was a consensus on
>> [draft-ietf-ccamp-assoc-info-01.txt] to separate it into two drafts:
>> (1)Usage of The RSVP Association Object
>> (2)RSVP Association Object Extensions
>>  
>> So, I think it is appropriate to address MPLS-TP bidirectional LSP
>> association in the draft (2), because we know that one of the key
>> drivers for Association Object Extensions in
>> [draft-ietf-ccamp-assoc-info-01] is for MPLS-TP.
>>  
>> In this way, we can just keep two drafts for the association stuff
>> (besides RFC4872 and RFC4873), one is "informational usage for GMPLS
>> recovery", another one is for "Standards track extensions for non-GMPLS
>> recovery usage and Extended association". Another benefit  of this
>> approach is very easy for the readers to track and review the RFCs.
>>  
>>  
>>  
>> 
>> Thanks
>>  
>> Fatai
>>  
>> Huawei Technologies Co., LTD.
>> Huawei Base, Bantian, Longgang,
>> Shenzhen 518129 P.R.China
>> Tel: +86-755-28972912
>> Fax: +86-755-28972935
>> ----- Original Message -----
>> From: "Lou Berger" <lberger@labn.net <mailto:lberger@labn.net>>
>> To: <ccamp@ietf.org <mailto:ccamp@ietf.org>>
>> Sent: Friday, April 01, 2011 5:24 PM
>> Subject: [CCAMP] poll on
>> makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document
>> 
>>> All,
>>>
>>> This is to start a two week poll on making
>>> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a ccamp working
>>> group document. Please send mail to the list indicating "yes/support"
>>> or "no/do not support".  If indicating no, please state your technical
>>> reservations with the document.
>>>
>>> The poll ends Friday April 15.
>>>
>>> Much thanks,
>>> Lou (and Deborah)
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org <mailto:CCAMP@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>