Re: [bfcpbis] Documentation structure for bfcpbis

[Tom Kristensen <[e-mail]>]

Inline.

On 06/01/2012, Charles Eckel (eckelcu) <[e-mail]> wrote:
> (As an individual)
> Please see comments inline.
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of DRAGE, Keith (Keith)
>> Sent: Thursday, January 05, 2012 6:27 AM
>> To: [e-mail]
>> Subject: [bfcpbis] Documentation structure for bfcpbis
>>
>> (As WG cochair)
>>
>> I'd like to initiate some discussion on the documentation structure of
>> what we want produce in the bfcpbis working group.
>>
>> There have been a couple of comments on rolling into the existing BFCP
>> RFC and we have at least a few options round here. Here at least are a
>> few thoughts:
>>
>> What
>> ----
>>
>> As a working group we have at least a couple of issues to address:
>>
>> -	identify what we want in terms of compatibility with the
> existing
>> BFCP (at the moment I am assuming that any new implementation would
>> interoperate with the existing BFCP at least using TCP, but we have
> not
>> had a discussion on that)
>
> I agree. To date, we have not specified any changes to the RFC 4582
> specification when using TCP. Based on discussion at IETF 82, we planned
> to change the BFCP protocol version number from 1 to 2 when using UDP
> per RFC 4582-bis, but there was no decision on what to do when using
> TCP. To date, I do not see any need to specify version 2 when using TCP.

Since no changes have been proposed for TCP/BFCP, incrementing the
protocol version to indicate usage of RFC4582bis UDP/BFCP seems to be
a good path forward.

>> -	identify the best way of presenting the material that works for
>> people doing completely new implementations versus thus updating
>> existing implementations.
>>
>> If we need to be able to identify differences there are a number of
>> ways of doing this including: 1) rely on the difference tools at
>> tools.ietf.org and ensure that any WG output produces a true
> difference
>> to the existing RFC, 2) carry forward any differences to the existing
>> RFC in an annex or appendix (with the main body being the full text)
>> and 3) keep the document solely as a difference document. There is of
>> course a fourth option of ignoring identifying any differences at all.
>
> The changes to date have been specific to UDP, and I anticipate that any
> changes applicable to TCP will be minimal and not require any
> restructuring of the existing BFCP RFCs. As such, I think we will
> eventually be able to roll the set of differences captured in the WG
> draft into an updated version of RFC 4582. This being the case, option 1
> is my preference.

This is my preference too. The draft is currently structured as a
'diff' for RFC4582bis and RFC4583bis.

We may add a new section/subsection with a guide to what's new to
assist people implementing the entire new RFCs or actually people
wanting to add UDP/BFCP support to an existing TCP/BFCP
implementation.

>> When
>> ----
>>
>> We also have options in terms of when we change the document to
>> whatever format we decide. We could do it immediately, or we could
>> progress through the working group discussion and WGLC on the existing
>> structure and only make the change at, for example, publication
>> request. Doing the latter would focus the working group on changing
>> only those bits that meet completing the immediate charter of the
>> working group, but may be more difficult to work with. Doing the
> former
>> may open up the working group to addressing a complete second edition,
>> with any number of miscellaneous enhancements to the existing BFCP.
>
> I think the sooner the better. Once the set of changes seems stable,
> perhaps based on draft-ietf-bfcpbis-rfc4582bis-00, we could make the
> change in format.

As requested by Keith Drage, the -00 version (submitted today) has
only editorial changes and serves as a basis WG document for further
work. I'd like the -01 version to be a proper RFC4582bis, i.e. merging
in the changes and polishing the format.

-- Tom

[...]

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/