Re: [forces] CEHA shepherding

[Joel <[e-mail]>]

The error is the long lines.  Which can be dealt with by the RFC Series 
Production Center.
Yours,
Joel

On 6/4/2013 2:49 PM, Jamal Hadi Salim wrote:
> Joel,
> According to this:
> https://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-forces-ceha-07.txt
>
> There is one error and 4 warnings (unless that is a bug in the tool)
>
> cheers,
> jamal
>
>
>
> On Tue, Jun 4, 2013 at 2:37 PM, Joel <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     None of those warnings warrant a respin.
>     If the draft gets spun for some other reason, and if we have not
>     added any any 2119 language to the draft, then we should remove the
>     reference.
>
>     Yours,
>     Joel
>
>
>     On 6/4/2013 1:35 PM, [e-mail]
>     <mailto:[e-mail]> wrote:
>
>         Hi Jamal,
>         Thanks for confirming the IPR related matters.
>         PLS note that I found the following ID nits by checking the draft
>         (http://www.ietf.org/id/draft-__ietf-forcesceha-07.txt
>         <http://www.ietf.org/id/draft-ietf-forcesceha-07.txt>) through
>         the website:
>         http://www.ietf.org/tools/__idnits/
>         <http://www.ietf.org/tools/idnits/>
>         The question is whether the draft should be revised based
>         on the reqd. fixes before publishing. Thanks.
>         Best.
>         Bhumip
>         +++++++++++++++++++++START++++__++++++++++++++++++++
>
>         idnits 2.12.17
>
>         /tmp/draft-ietf-forces-ceha-__07.txt:
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(90): update_references( The
>         following
>
>         definitions are taken from [RFC3654]and [RFC3746]:)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(96): update_references( the
>         ForCES
>
>         Framework in [RFC3746].)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(100): update_references(
>         transfer
>
>         mechanisms as defined in [RFC5810].)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(229): update_references( by
>         the FEPO
>
>         LFB in [RFC5810], Appendix B. In Section 3.1 of this)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(247): update_references( 1. To
>
>         describe with more clarity (than [RFC5810]) how current cold-)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(250): update_references( 2. To
>
>         describe how to evolve the [RFC5810] cold-standby setup to a)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(267): update_references(
>         The design
>
>         intent of the current [RFC5810] as well as this document)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(271): update_references(
>         setup in
>
>         [RFC5810]:)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(313): RFC 2119 keyword: To
>         achieve CE
>
>         High Availability (HA), FEs and CEs MUST inter-operate.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(314): update_references(
>         per [RFC5810]
>
>         definition which is repeated for contextual reasons in)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(316): RFC 2119 keyword: MUST be
>
>         implemented by CEs and FEs requiring HA, the Fr plane is out.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(377): update_references( a
>         detected
>
>         failure. The FEObject FEState component [RFC5812] defines)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(380): update_references(
>         and can turn
>
>         it on by setting it to OperEnable. Note: [RFC5812])
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(425): Line has weird
>         spacing: '... |try
>
>         v...'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(456): RFC 2119 keyword:
>         communication
>
>         failure, regardless of how it is detected, MUST be.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(468): RFC 2119 keyword:
>         timer [RFC5810]
>
>         is started. The FE MAY continue to forward packets.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(468): update_references( timer
>
>         [RFC5810] is started. The FE MAY continue to forward packets)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(476): update_references(
>         bring down its
>
>         forwarding path (and set the [RFC5812] FEObject)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(538): RFC 2119 keyword:
>         MUST configure
>
>         the FE to make it aware which CE is the master and MAY.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(657): RFC 2119 keyword: CE
>         (lowest
>
>         table index) in the AllCEs table MUST be the first CE that.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(662): RFC 2119 keyword: FE MUST
>
>         associate with at least one CE. Upon a successful.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(678): RFC 2119 keyword: FE.
>
>         Configuration messages (SET/DEL) from backup CEs MUST be dropped.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(710): Line is too long: the
>         offending
>
>         characters are '+'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(711): Line is too long: the
>         offending
>
>         characters are '|'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(712): Line is too long: the
>         offending
>
>         characters are 'v'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(712): Line has weird
>         spacing: '...ociated
>
>         v...'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(713): Line is too long: the
>         offending
>
>         characters are '|'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(713): Line has weird
>         spacing: '...)|CE or
>
>         retry...'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(714): Line is too long: the
>         offending
>
>         characters are '|'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(715): Line is too long: the
>         offending
>
>         characters are '+'
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(779): RFC 2119 keyword:
>         associating
>
>         with the master CE, MUST attempt to connect and associate.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(792): RFC 2119 keyword: FE
>         MAY flag
>
>         them as unreachable to avoid continuous attempts to.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(793): RFC 2119 keyword:
>         connect. The
>
>         FE MAY retry to reassociate with unreachable CEs when.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(797): RFC 2119 keyword: FE
>         MUST try to
>
>         find the first associated CE from the list of all CEs.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(801): RFC 2119 keyword: it
>         MUST attempt
>
>         to connect and associate with the first from the list.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(835): update_references(
>         Security
>
>         consideration as defined in section 9 of [RFC5810] applies.)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(850): update_references(
>         [RFC2119]
>
>         Bradner, S., "Key words for use in RFCs to Indicate Requirement
>         Levels", BCP
>
>         14, RFC 2119, March 1997.)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(855): update_references(
>         [RFC5810] Doria,
>
>         A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L.,
>         Gopal, R.,
>
>         and J. Halpern, "Forwarding and Control Element Separation
>         (ForCES) Protocol
>
>         Specification", RFC 5810, March 2010.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(860): update_references(
>         [RFC3654]
>
>         Khosravi, H. and T. Anderson, "Requirements for Separation of IP
>         Control and
>
>         Forwarding", RFC 3654, November 2003.)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(864): update_references(
>         [RFC3746] Yang,
>
>         L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and
>         Control Element
>
>         Separation (ForCES) Framework", RFC 3746, April 2004.)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(868): update_references(
>         [RFC5812]
>
>         Halpern, J. and J. Hadi Salim, "Forwarding and Control Element
>         Separation
>
>         (ForCES) Forwarding Element Model", RFC 5812, March 2010.)
>
>         .
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(869): Appendix start:
>         Appendix A. New
>
>         FEPO version.
>
>         /tmp/draft-ietf-forces-ceha-__07.txt(871): update_references(
>         The xml has
>
>         been validated against the schema defined in [RFC5812].)
>
>         .
>
>         update_references( The following definitions are taken from
>
>         [RFC3654]and [RFC3746]:)
>
>         update_references( the ForCES Framework in [RFC3746].)
>
>         update_references( transfer mechanisms as defined in [RFC5810].)
>
>         update_references( by the FEPO LFB in [RFC5810], Appendix B. In
>
>         Section 3.1 of this)
>
>         update_references( 1. To describe with more clarity (than [RFC5810])
>
>         how current cold-)
>
>         update_references( 2. To describe how to evolve the [RFC5810]
>
>         cold-standby setup to a)
>
>         update_references( The design intent of the current [RFC5810] as
>         well
>
>         as this document)
>
>         update_references( setup in [RFC5810]:)
>
>         update_references( per [RFC5810] definition which is repeated for
>
>         contextual reasons in)
>
>         update_references( a detected failure. The FEObject FEState
>
>         component [RFC5812] defines)
>
>         update_references( and can turn it on by setting it to OperEnable.
>
>         Note: [RFC5812])
>
>         update_references( timer [RFC5810] is started. The FE MAY continue
>
>         to forward packets)
>
>         update_references( bring down its forwarding path (and set the
>
>         [RFC5812] FEObject)
>
>         update_references( Security consideration as defined in section 9 of
>
>         [RFC5810] applies.)
>
>         update_references( [RFC2119] Bradner, S., "Key words for use in
>         RFCs to
>
>         Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.)
>
>         ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key words for
>         use in
>
>         RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>         update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R.,
>
>         Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern,
>         "Forwarding
>
>         and Control Element Separation (ForCES) Protocol Specification", RFC
>
>         5810, March 2010.)
>
>         ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim, J., Haas,
>
>         R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern,
>
>         "Forwarding and Control Element Separation (ForCES) Protocol
>
>         Specification", RFC 5810, March 2010.
>
>         update_references( [RFC3654] Khosravi, H. and T. Anderson,
>
>         "Requirements for Separation of IP Control and Forwarding", RFC
>         3654,
>
>         November 2003.)
>
>         ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. Anderson,
>
>         "Requirements for Separation of IP Control and Forwarding", RFC
>         3654,
>
>         November 2003.
>
>         update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T.,
>         and R.
>
>         Gopal, "Forwarding and Control Element Separation (ForCES)
>         Framework",
>
>         RFC 3746, April 2004.)
>
>         ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R.,
>         Anderson, T.,
>
>         and R. Gopal, "Forwarding and Control Element Separation (ForCES)
>
>         Framework", RFC 3746, April 2004.
>
>         update_references( [RFC5812] Halpern, J. and J. Hadi Salim,
>         "Forwarding
>
>         and Control Element Separation (ForCES) Forwarding Element
>         Model", RFC
>
>         5812, March 2010.)
>
>         ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Hadi Salim,
>
>         "Forwarding and Control Element Separation (ForCES) Forwarding
>         Element
>
>         Model", RFC 5812, March 2010.
>
>         Appendix start: Appendix A. New FEPO version
>
>         update_references( The xml has been validated against the schema
>
>         defined in [RFC5812].)
>
>         Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
>
>         Errors MUST be fixed before draft submission. Flaws SHOULD be
>         fixed before
>
>         draft submission.
>
>         Checking boilerplate required by RFC 5378 and the IETF Trust (see
>
>         http://trustee.ietf.org/__license-info
>         <http://trustee.ietf.org/license-info>):
>
>         ------------------------------__------------------------------__---------------
>
>         No issues found here.
>
>         Checking nits according to
>         http://www.ietf.org/id-info/__1id-guidelines.txt
>         <http://www.ietf.org/id-info/1id-guidelines.txt>:
>
>         ------------------------------__------------------------------__---------------
>
>         No issues found here.
>
>         Running in submission checking mode -- *not* checking nits
>         according to
>
>         http://www.ietf.org/id-info/__checklist
>         <http://www.ietf.org/id-info/checklist> .
>
>         ------------------------------__------------------------------__---------------
>
>         No nits found.
>
>         +++++++++++++++++++++END++++++__++++++++++++++++++
>
>
>         On Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim
>         <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>
>              Thanks Bhumip.
>              I can verify that no IPR issues were ever brought up by the
>         authors
>              or any one
>              attending the WG or on the lists over the years in regards
>         to the
>              contents of this
>              document.
>
>              cheers,
>              jamal
>
>
>              On Mon, Jun 3, 2013 at 11:31 AM, [e-mail]
>         <mailto:[e-mail]>
>              <mailto:[e-mail]
>         <mailto:[e-mail]>> <[e-mail]
>         <mailto:[e-mail]>
>
>              <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>
>                  Thanks Jamal.
>                  Pls note that to the best of my knowledge there is no
>         IPR issue
>                  involved with this draft.
>                  In addition, I have not heard any objection re
>         publishing this
>                  as well.
>                  I'll finalize the shepherd's writeup soon. Thanks again.
>                  Best.
>                  Bhumip
>
>
>                  On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim
>                  <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>
>
>                      Bhumip has graciously agreed to shepherd the CEHA
>         draft:
>         https://datatracker.ietf.org/__doc/draft-ietf-forces-ceha/
>         <https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/>
>
>                      This the last outstanding document from the
>         previous charter
>                      that
>                      has not started the publication journey.
>
>                      Thanks Bhumip.
>
>                      cheers,
>                      jamal
>
>                      _________________________________________________
>                      forces mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/__listinfo/forces
>         <https://www.ietf.org/mailman/listinfo/forces>
>
>
>
>
>
>
>
>
>
>         _________________________________________________
>         forces mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/forces
>         <https://www.ietf.org/mailman/listinfo/forces>
>
>