Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Thanks Mach! We will fix them.

Thanks,

/Yimin

-----Original Message-----
From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Mach Chen
Sent: Tuesday, July 29, 2014 4:41 AM
To: Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

I have read the draft and think it's ready for publication.

BTW, I run the idnits tool and found the following nits, they need to be solved before the publication.

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).

     Found 'MAY NOT' in this paragraph:

     In this model, the protector is a dedicated P router or PE router
     that serves the role.  In egress AC protection and egress PE node
     protection, the protector MAY or MAY NOT be a backup PE with a direct
     connection to the target CE.  In S-PE node protection, the protector MAY
     or MAY NOT be a backup S-PE on the backup PW.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).

     Found 'MAY NOT' in this paragraph:

     At any given time, each CE sends traffic via only one AC and
     receives traffic via only one AC.  The two ACs MAY or MAY NOT be the
     same. The AC used to send traffic is determined by the CE, and MAY rely
     on an end-to-end OAM mechanism between the CEs.  The AC used for the CE
     to receive traffic is determined by the state of the network and the
     protection mechanism in use, as described later in this document.

  -- The document date (July 24, 2014) is 5 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC3985' is defined on line 1153, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5659' is defined on line 1156, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4447' is defined on line 1160, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5331' is defined on line 1164, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5036' is defined on line 1168, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5561' is defined on line 1171, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2205' is defined on line 1174, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3209' is defined on line 1178, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4090' is defined on line 1182, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5286' is defined on line 1186, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5714' is defined on line 1189, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3471' is defined on line 1192, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3472' is defined on line 1196, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3031' is defined on line 1201, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2328' is defined on line 1204, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5880' is defined on line 1206, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6389' is defined on line 1209, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5920' is defined on line 1219, but no explicit
     reference was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 3985

  ** Downref: Normative reference to an Informational RFC: RFC 5659

  ** Downref: Normative reference to an Informational RFC: RFC 5714

     Summary: 3 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

Best regards,
Mach

> -----Original Message-----
> From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew
> (Matthew)
> Sent: Friday, July 25, 2014 10:56 PM
> To: pwe3@ietf.org
> Subject: [PWE3] WG Last Call for 
> draft-ietf-pwe3-endpoint-fast-protection-01
> 
> This email begins a second two week working group last call for
> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 .
> 
> Please review the draft and post any comments to the PWE3 list.
> 
> If you have read the draft, even if you don¹t have any comments, but 
> would like to see the draft progressed,  please can you indicate this to the list.
> 
> This working group last call will end on Friday August 8th, 2014.
> 
> 
> Best regards
> 
> 
> Matthew and Andy
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3