Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02

Hi Andy,

I hope you don't mind me commenting on part of your note below.

Regarding the definition of "SFC Encapsulation", indeed there were participants that requested a looser wording; but for completeness, there were also participants that requested the definition to stay as.

Of course, as a WG document the editors capture the results of the group's work, and the document reflects decisions made by the WG. In fact, that has been our attempt all along even as an individual submission (with the goal of converging the sfc architecture). And I expect the WG to continue discussing the architecture.

Thank you again,

Carlos.
PS: From a technical perspective (not to re-open the discussion here, but only to point at where that discussion faded out), the proposed text would hamper interoperability while the mentioned downsides seemed adequately covered in the "MTU and Fragmentation Considerations" section of the document.

On Aug 26, 2014, at 1:07 PM, Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>> wrote:

Jim,

I support the adoption of this draft by the WG.

During the discussion of revision -01, although a number of WG participants requested a more flexible wording of the SFC encapsulation definition, it was unchanged from -01 to -02. This is within the rights of individual authors, of course. However, once this becomes a WG draft, I hope we can revisit that discussion.

Thanks,
Andy

On Tue, Aug 26, 2014 at 7:40 AM, Jim Guichard (jguichar) <jguichar@cisco.com<mailto:jguichar@cisco.com>> wrote:
Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sfc-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval or disapproval.

As always, please note:

  1.  This is not WG Last Call. The document is not final, and the WG is expected to modify the document’s content until there is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its content.
  2.  If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
  3.  If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc