Re: [Idr] [Technical Errata Reported] RFC4271 (4493)

[<[e-mail]>]

Hi Tom,

Please see inline

> From: t.petch [mailto:[e-mail]] > Sent: Wednesday, February 17, 2016 6:15 PM
> 
> ----- Original Message -----
> From: "Alvaro Retana (aretana)" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, February 17, 2016 3:08 PM
> 
> Idr WG:
> 
> Please take a look at the Errata below.  I need your opinion on it.
> 
> I'm leaning towards rejecting it because I interpret "Unspecific" not as
> the name of the subcode, but as just an indication that the error is not
> specific.  The IANA registry [1] lists the value 0 as "Reserved", which
> I
> think is ok according to the definition in RFC5226:
> 
> <tp>
> 
> Reject.
> 
> s.6.2 specifies a specific(!) instance of using 0(Unspecific) (so I
> think that IANA is in error here).  Arguably, you could raise an erratum
> to add 0(Unspecific) for the OPEN Message Error subcodes list 

Agreed.

> but I
> think that it would be a technical change to add it for the other
> messages.  As currently defined, it could be seen as an implementation
> error were subcode 0 be used for the other messages (an interpretation
> which I have no problem with).

I don't think you can call "implementation error" a behavior which is specified in the RFC:
"If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field."
https://tools.ietf.org/html/rfc4271#section-4.5

This sentence is generic and applies to all error codes.

Accepting the errata or not is a different story.

-- Bruno


> If there are errors that cannot be reported using the subcodes in
> RC4271, then that is a separate issue that could be worth investigating.
> 
> Tom Petch
> 
> 
>       Reserved:  Not to be assigned.  Reserved values are held for
>             special uses, such as to extend the namespace when it become
>             exhausted.  Reserved values are not available for general
>             assignment.
> 
> In this case the "special use" is when the error is not specific.
> 
> Any thoughts?  Other opinions?
> 
> Thanks!
> 
> Alvaro.
> 
> [1]
> http://www.iana.org/assignments/bgp-parameters/bgp-
> parameters.xhtml#bgp-
> par
> ameters-4
> 
> On 10/6/15, 4:10 AM, "RFC Errata System" <[e-mail]>
> wrote:
> 
> >The following errata report has been submitted for RFC4271,
> >"A Border Gateway Protocol 4 (BGP-4)".
> >
> >--------------------------------------
> >You may review the report below and at:
> >http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=4493
> >
> >--------------------------------------
> >Type: Technical
> >Reported by: Bruno Decraene <[e-mail]>
> >
> >Section: 4.5
> >
> >Original Text
> >-------------
> >§\\"4.5 NOTIFICATION Message Format\\" says:
> >
> >      Message Header Error subcodes:
> >
> >               1 - Connection Not Synchronized.
> >               2 - Bad Message Length.
> >               3 - Bad Message Type.
> >
> >      OPEN Message Error subcodes:
> >
> >               1 - Unsupported Version Number.
> >               2 - Bad Peer AS.
> >               3 - Bad BGP Identifier.
> >               4 - Unsupported Optional Parameter.
> >               5 - [Deprecated - see Appendix A].
> >               6 - Unacceptable Hold Time.
> >
> >      UPDATE Message Error subcodes:
> >
> >               1 - Malformed Attribute List.
> >               2 - Unrecognized Well-known Attribute.
> >               3 - Missing Well-known Attribute.
> >               4 - Attribute Flags Error.
> >               5 - Attribute Length Error.
> >               6 - Invalid ORIGIN Attribute.
> >               7 - [Deprecated - see Appendix A].
> >               8 - Invalid NEXT_HOP Attribute.
> >               9 - Optional Attribute Error.
> >              10 - Invalid Network Field.
> >              11 - Malformed AS_PATH.
> >
> >Corrected Text
> >--------------
> >      Message Header Error subcodes:
> >
> >               0 - Unspecific.
> >               1 - Connection Not Synchronized.
> >               2 - Bad Message Length.
> >               3 - Bad Message Type.
> >
> >      OPEN Message Error subcodes:
> >
> >               0 - Unspecific.
> >               1 - Unsupported Version Number.
> >               2 - Bad Peer AS.
> >               3 - Bad BGP Identifier.
> >               4 - Unsupported Optional Parameter.
> >               5 - [Deprecated - see Appendix A].
> >               6 - Unacceptable Hold Time.
> >
> >      UPDATE Message Error subcodes:
> >
> >               0 - Unspecific.
> >               1 - Malformed Attribute List.
> >               2 - Unrecognized Well-known Attribute.
> >               3 - Missing Well-known Attribute.
> >               4 - Attribute Flags Error.
> >               5 - Attribute Length Error.
> >               6 - Invalid ORIGIN Attribute.
> >               7 - [Deprecated - see Appendix A].
> >               8 - Invalid NEXT_HOP Attribute.
> >               9 - Optional Attribute Error.
> >              10 - Invalid Network Field.
> >              11 - Malformed AS_PATH.
> >
> >Notes
> >-----
> >RFC 4271 defines a use and a name for Error subcode 0:
> >- §4.5 (any error code):
> >         If no appropriate Error Subcode is defined, then a zero
> >         (Unspecific) value is used for the Error Subcode field.
> >
> >- §6.2 (OPEN error code):
> >   If one of the Optional Parameters in the OPEN message is recognized,
> >   but is malformed, then the Error Subcode MUST be set to 0
> >   (Unspecific).
> >
> >If verified, the \\"IANA Considerations\\" section and the IANA
> registry
> >would also need to be updated accordingly (currently says \\"0
> >Reserved\\")
> >http://www.iana.org/assignments/bgp-parameters/bgp-
> parameters.xhtml#bgp
> -pa
> >rameters-4
> >
> >Instructions:
> >-------------
> >This erratum is currently posted as "Reported". If necessary, please
> >use "Reply All" to discuss whether it should be verified or
> >rejected. When a decision is reached, the verifying party (IESG)
> >can log in to change the status and edit the report, if necessary.
> >
> >--------------------------------------
> >RFC4271 (draft-ietf-idr-bgp4-26)
> >--------------------------------------
> >Title               : A Border Gateway Protocol 4 (BGP-4)
> >Publication Date    : January 2006
> >Author(s)           : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.
> >Category            : DRAFT STANDARD
> >Source              : Inter-Domain Routing
> >Area                : Routing
> >Stream              : IETF
> >Verifying Party     : IESG
> >
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.