Hi, [speaking as co-chair]
It appears to me that somehow we got out of sync. I want to make sure we are all in sync, so let me review where we are and where the chairs think this WG needs to go to get our ***chartered*** work done. Chris and I discussed the syslog-sign WGLC, and the need to update RFC3195 last week. The driving factor has been the syslog-sign WGLC. It is difficult to complete syslog-sign because it has dependencies on RFC3195. RRC3195 was written before the WG completed much of its current work, and there have been numerous WG consensus points reached since RFC3195 was published. Chris and I reached some agreement about what we felt was WG consensus on some of the issues, and we discussed with Sam (via email) what we believe is a necessary change to our charter - to bring RFC3195 into compliance with the WG consensus points achieved since its publication, before completing the work on syslog-sign. Our charter currently includes the completion of syslog-sign, and does not include RFC3195bis, so updating RFC3195 first might require a change to the charter. So we asked Sam if we could add RFC3195bis to our charter to complete it before completing syslog-sign. Sam told us he would be OK with such a change, and that we should draft a charter change, but to feel free to start the work in the meantime. Let me be very clear - we do not have the AD official approval of the charter change yet, just a verbal approaval of our intent. Making such a change to the charter might be able to be done without discussion with the WG, but I would like the WG involved in the decision to make such a change. The WG consensus points that affect syslog-sign dependencies on RFC3195 are: 1) remove RFC3195 references to RFC3164, and use the WG -protocol- document as the appropriate replacement reference. 2) There should be a separation of transport mappings from protocol, in the same way that the UDP and TLS transport mappings have been separated from the protocol. i.e., make RFC3195 a BEEP transport mapping independent of protocol processing. 3) syslog-sign should remove dependencies on specific transport mappings, to make it transport-mapping-independent. This would allow us to remove the syslog-sign dependencies on RFC3195. 4) As a result of the RFC3195bis work, the status of RFC3195 would become "obsolete". That is what Chris and I agreed to, and that is effectively what was proposed to Sam as the change to our charter (I wasn't as wordy in the request). -- Chris and I also discussed RAW and Cooked mode. Achieving #3 may be straightforward vis-a-vis RAW mode. Achieving #3 may be difficult vis-a-vis COOKED mode. Cooked mode creates interdependencies between the BEEP transport and syslog processing. This creates complications with achieving #3, but there are probably workarounds. It appears that Cooked mode has not been widely implemented, and Chris and I agreed that previous discussions on the list indicated limited interest in cooked mode. As part of this work, we recognized that we might reach WG consensus to eliminate cooked mode from RFC3195bis. -- Something got lost in the translation to the editors. Chris and I did not agree that Cooked mode should be obsoleted. We agreed that it should be discussed on the list to see if that was WG consensus. Chris and I did not agree that RAW mode should be obsoleted and replaced with a new mode. That is new work that is NOT in the current charter, and is not in the proposal to Sam for a minor change to the charter. That is simply out of scope for the current WG. To my knowledge, there has been no discussion of such a change, and there is no current WG consensus to do this, even if it were in scope. As co-chair, I would not take such a proposal to Sam because we have work that is not yet completed, and that needs to be completed before we start working on new proposals. If there is WG consensus to obsolete both RAW and COOKED modes, then we can simply obsolete RFC3195 and move forward with sylog-sign. A new proposal for a TARTARE mode can be proposed as a new transport mapping in the future, under a different charter or as an individual draft. Security considerations in RFC3195 would obviously need to be reviewed and possibly rewritten in light of the use of -protocol- rather than RFC3164. That does NOT open the door to redesigning RFC3195 in any substantial manner to address algorithm agility. We may need to do this, but that has not yet been discussed on the list, with the chairs, or with the AD. Currently, I would consider that out of scope, while recognizing that we may need to make modifications before it can be submitted for standardization. And do not misinterpret "do people desire any other changes" because we are not accepting new proposals. We are trying to complete the work on our plate. Hopefully, this helps clarify the proposed WG work plans. As part of having the change made to the charter, Chris and I have also discussed updating the WG deadlines, since we missed our November deadlines for -sign- and -mib-. We plan to post a new schedule soon. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Co-chair, syslog WG _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
