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

From: <[email-masked]>
Date: Tue, 1 Mar 2016 14:21:07 +0000

Hi Tom,

Please see inline [Bruno2]

> From: t.petch [mailto:[email-masked]] > Sent: Tuesday, February 23, 2016 12:47 PM

> <inline>

> Tom Petch

> ----- Original Message -----

> From: <[email-masked]<mailto:[email-masked]>>

> To: "t.petch" <[email-masked]<mailto:[email-masked]>>; "Alvaro Retana (aretana)"

> <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>

> Sent: Thursday, February 18, 2016 9:08

> Hi Tom,

> Please see inline

> > From: t.petch [mailto:[email-masked]] > Sent: Wednesday, February

> 17, 2016 6:15 PM

> > ----- Original Message -----

> > From: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>

> > To: <[email-masked]<mailto:[email-masked]>>

> > Cc: <[email-masked]<mailto:[email-masked]>>

> > 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.

> <tp>

> Ah yes, my mistake.

> On balance, I would still support an Erratum that updates "OPEN Message

> Error subcodes:" but would see updating all the lists of subcodes as

> going too far.

> A zero subcode for any other message is not something that the IDR WG

> could think of a reason for, unlike the case of OPEN, so while calling

> it an error is wrong, it remains something unusual, unexpected.  Adding

> it to all the lists of subcodes would seem to go beyond what the IDR WG

> consented to when it produced RFC4271.

[Bruno2]

I'm not asking to change the protocol specification (RFC 4271).

I'm asking that the IANA section and the IANA registry be updated so that the sub-code "0" be marked as already allocated, so that we don't risk a collision in some hypothetical future.

And I'm quoting the existing RFC 4271 stating that the use of this sub-code 0 _is_ specified in RFC 4271,  for _all_ error code. I'm reading it in RFC 4271 at least twice:

6.1.  Message Header Error Handling

[...]

   When any of the conditions described here are detected, a

   NOTIFICATION message, with the indicated Error Code, Error Subcode,

   and Data fields, is sent, and the BGP connection is closed (unless it

   is explicitly stated that no NOTIFICATION message is to be sent and

   the BGP connection is not to be closed).  If no Error Subcode is

   specified, then a zero MUST be used.

https://tools.ietf.org/html/rfc4271#section-6

And as already stated, in

4.5.  NOTIFICATION Message Format

[...]

      Error Code:

         This 1-octet unsigned integer indicates the type of

         NOTIFICATION.  The following Error Codes have been defined:

            Error Code       Symbolic Name               Reference

              1         Message Header Error             Section 6.1

              2         OPEN Message Error               Section 6.2

              3         UPDATE Message Error             Section 6.3

              4         Hold Timer Expired               Section 6.5

              5         Finite State Machine Error       Section 6.6

              6         Cease                            Section 6.7

      Error subcode:

         This 1-octet unsigned integer provides more specific

         information about the nature of the reported error.  Each Error

         Code may have one or more Error Subcodes associated with it.

         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

You may disagree with my reading of RFC4271, but if so, please quote/discuss RFC 4271 text

-- Bruno

> Tom Petch

> 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" <[email-masked]<mailto:[email-masked]>>

> > 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 <[email-masked]<mailto:[email-masked]>>

> > >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<file:///\\%22IANA> Considerations\\" section and the IANA

> > registry

> > >would also need to be updated accordingly (currently says \\"0<file:///\\%220>

> > >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

> > [email-masked]<mailto:[email-masked]>

> > 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.

_________________________________________________________________________________________________________________________

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.