Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
That all sounds good, thanks! Ben. > On Jan 22, 2019, at 2:59 AM, Ali Sajassi (sajassi) wrote: > > Ben, > Thanks for your review and your comments. Please refer to my replies below > marked with "AS>". > > On 1/9/19, 1:28 PM, "Ben Campbell" <mailto:b...@nostrum.com>> wrote: > >Ben Campbell has entered the following ballot position for >draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ > > > >-- >COMMENT: >-- > >Thanks for the work on this. > >I support Alissa's discuss. > >§2: >- The 2119/8174 keywords in this section are not used according to the RFC >2119/RFC 8174 definitions. The RFCs talk about requirements on > implementations >to achieve interoperability. This speaks of requirements for the standards >process. If the working group prefers to keep the use of keywords in this >section, please add some additional text to the 2119/8174 boilerplate to >explain the usage. (My other comments on the section assume that the > normative >keywords will remain.) > >- Req 2: "The solution MUST require no changes..." >I suggest "MUST NOT require changes" > > AS> Changed it to: "must not require any changes to ..." > >- Req 5: This doesn't seem to state a solution requirement; rather, it >describes an action that VPN instances may take. Is the solution > requirement to >allow this behavior? > > AS> moved the 2nd part of the paragraph to the solution description under > sections 3.2 and 4.2. > > Regards, > Ali signature.asc Description: Message signed with OpenPGP ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Ben Campbell's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ -- COMMENT: -- Thanks for the work on this. I support Alissa's discuss. §2: - The 2119/8174 keywords in this section are not used according to the RFC 2119/RFC 8174 definitions. The RFCs talk about requirements on implementations to achieve interoperability. This speaks of requirements for the standards process. If the working group prefers to keep the use of keywords in this section, please add some additional text to the 2119/8174 boilerplate to explain the usage. (My other comments on the section assume that the normative keywords will remain.) - Req 2: "The solution MUST require no changes..." I suggest "MUST NOT require changes" - Req 5: This doesn't seem to state a solution requirement; rather, it describes an action that VPN instances may take. Is the solution requirement to allow this behavior? ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-mvpn-expl-track-12: (with COMMENT)
Excellent, thanks! > On Oct 24, 2018, at 4:29 PM, Vigoureux, Martin (Nokia - FR/Paris-Saclay) > wrote: > > Ben, > > thank you for your review. > Regarding your substantive COMMENT: the disclosure came at the time of > WG adoption. The WG was thus specifically informed of that and given an > extra week to (re)consider the positions already expressed. > > The existence of the IPR was also mentioned and referenced in the WG > Last Call e-mail. > > -m > > Le 2018-10-24 à 23:02, Ben Campbell a écrit : >> Ben Campbell has entered the following ballot position for >> draft-ietf-bess-mvpn-expl-track-12: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ >> >> >> >> -- >> COMMENT: >> -- >> >> Thanks for the work on this! >> >> *** Substantive Comments *** >> >> I support Mirja's DISCUSS. >> >> - There is an IPR disclosure with possible royalties. The shepherd report >> says >> there were no WG objections. How was the disclosure communicated? For >> example, >> was the WG reminded of the disclosure at WGLC? >> >> *** Editorial Comments *** >> >> §3: >> - Part way through the section, starting with "We also introduce a new >> notion, >> the "match for tracking":", there is a section of text that has a >> significantly >> different tone from the rest of the draft. It switches more of a lecture >> style, >> then switches back. I suggest an edit pass to keep a consistent tone. (I >> know >> this is a question of style, and I will not press it further if people prefer >> not to change it.) >> >> - 2 paragraphs starting with "For a given C-flow..." >> Why is this indented? >> >> >> ___ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> signature.asc Description: Message signed with OpenPGP ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Ben Campbell's No Objection on draft-ietf-bess-mvpn-expl-track-12: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-bess-mvpn-expl-track-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ -- COMMENT: -- Thanks for the work on this! *** Substantive Comments *** I support Mirja's DISCUSS. - There is an IPR disclosure with possible royalties. The shepherd report says there were no WG objections. How was the disclosure communicated? For example, was the WG reminded of the disclosure at WGLC? *** Editorial Comments *** §3: - Part way through the section, starting with "We also introduce a new notion, the "match for tracking":", there is a section of text that has a significantly different tone from the rest of the draft. It switches more of a lecture style, then switches back. I suggest an edit pass to keep a consistent tone. (I know this is a question of style, and I will not press it further if people prefer not to change it.) - 2 paragraphs starting with "For a given C-flow..." Why is this indented? ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Ben Campbell's No Objection on draft-ietf-bess-evpn-usage-08: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-bess-evpn-usage-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/ -- COMMENT: -- §10: It would help if the security considerations talked about how the security considerations from 7432 apply to the scenarios in this document, rather than just reference them. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Ben Campbell's No Objection on draft-ietf-bess-evpn-etree-13: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-bess-evpn-etree-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/ -- COMMENT: -- I share the questions about the prohibition of leaf-to-leaf communication. There's a fair amount of text enforcing such a requirement, but very little if any about why. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Ben Campbell's No Objection on draft-ietf-bess-pta-flags-03: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-bess-pta-flags-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ -- COMMENT: -- I do not suggest a change to the draft, but I am curious why the "Additional PMSI Tunnel Attribute Flags" registry needs a standards-action policy. It's pretty obvious why for the main flag registry, due to the small value-space. Are people concerned that the Additional flag will also run out of space? Or that people will define "bad" or non-interoperable extensions? ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-bess-virtual-subnet-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ -- COMMENT: -- Just a couple of editorial comments: - section 1, first paragraph, 2nd sentence: The sentence is confusing, and may suffer from an editing or copy-paste error. I'm not sure what "costly at the risk" of means. Also, who "generally admits" this to be true? ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-virtual-subnet-06: (with COMMENT)
On 2 Dec 2015, at 20:30, Xuxiaohu wrote: Hi Ben, Thanks for your comments. Please see my response inline. [...] -- COMMENT: -- Just a couple of editorial comments: - section 1, first paragraph, 2nd sentence: The sentence is confusing, and may suffer from an editing or copy-paste error. I'm not sure what "costly at the risk" of means. How about doing the following change: OLD: " It's generally admitted that IP renumbering of servers (i.e., VMs) after the migration is usually complex and costly at the risk of extending the business downtime during the process of migration. " NEW: "It's generally admitted that IP renumbering of servers (i.e., VMs) after the migration is usually complex and costly." That works to me, but see next comment. Also, who "generally admits" this to be true? I think the IETF community at least has admitted that. That's the reason why NVo3 WG is formed and several LAN or subnet extension proposals have been accepted by the IETF. If so, then how about "The IETF community has recognized..." Thanks! Ben. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Ben Campbell's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-bess-spbm-evpn-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ -- COMMENT: -- Section 4: Should this say MUST implement and perform...? Section 6 seems oddly placed. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
