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