Re: [Idr] draft-ietf-idr-error-handling-09.txt

[Deniz Bahadir <[e-mail]>]

My English seems not to be the best. I should probably replace 
"realized" with "identified" in my proposed-sentence.
I replaced it inline further down.

Deniz

Am 28.05.2014 13:13, schrieb Deniz Bahadir:
> Hi there,
>
> while trying to implement this draft I stumbled across a point which
> made me think if I really understood it correctly.
>
>
> The sentence I stumbled across is in section 3.g. of the draft:
>
> "[...] If any other attribute appears more than once in an UPDATE
> message, then all the occurrences of the attribute other than the first
> one SHALL be discarded and the UPDATE message continue to be processed."
>
> This pretty much says the same as the corresponding sentence from
> section 6.3 of RFC 4271 (except for the action taken):
>
> "If any attribute appears more than once in the UPDATE message, then the
> Error Subcode MUST be set to Malformed Attribute List."
>
>
> What I am asking myself (and now you) is:
> Does this really address *any* attribute which appears more than once,
> or only *recognized* attributes?
>
>
> Of course, my implementation could realize by the attribute's type-code
> that an unrecognized (most likely optional) attribute appeared more than
> once in an UPDATE-message. But maybe, that could be valid for that
> unrecognized path-attribute?
>
> So, if there is any chance of a (new) path-attribute to be allowed to
> appear more than once in an UPDATE-message, I would recommend to change
> the sentence in question to the following in the next version of this
> draft:
>
>
> "[...] If any other recognized attribute appears more than once in an
> UPDATE message, then all the occurrences of the attribute other than the
> first one SHALL be discarded and the UPDATE message continue to be
> processed. Unrecognized attributes are still allowed to appear more than
> once."
>
>
> If this it not what is intended, then I would recommend to explicitly
> state that this sentence is meant for recognized as well as unrecognized
> attributes, so that nobody might misinterpret it (as I might have done):
>

OLD:
> "[...] If any other attribute (no matter if recognized or not) appears
> more than once in an UPDATE message, then all the occurrences of the
> attribute other than the first one SHALL be discarded and the UPDATE
> message continue to be processed. (Multiple appearances of even
> unrecognized attributes can be be realized by the attributes' type-codes.)"

NEW:
"[...] If any other attribute (no matter if recognized or not) appears
more than once in an UPDATE message, then all the occurrences of the
attribute other than the first one SHALL be discarded and the UPDATE
message continue to be processed. (Multiple appearances of even
unrecognized attributes can be be identified by the attributes'
type-codes.)"


>
> (The sentence in parentheses is just for clarification and could be
> removed if it is too obvious.)
>
> Deniz
>
>
> Am 20.05.2014 09:19, schrieb Deniz Bahadir:
>> I have nothing to complain or to add.
>> Therefore, I support this draft being the final version and becoming an
>> RFC.
>>
>> Thanks for the good work,
>> Deniz
>>
>>
>> Am 19.05.2014 21:51, schrieb John G. Scudder:
>>> There are just a few relatively small changes in this version:
>>>
>>> - Note that when MP-BGP is in use, NEXT_HOP is discretionary.
>>> - Better text for NLRI section (thanks to Ondrej).
>>> - Fix typos.
>>>
>>> With luck, we are spiraling in to a final version.
>>>
>>> Thanks, all.
>>>
>>> --John
>>>
>>> On May 19, 2014, at 3:33 PM, [e-mail] wrote:
>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Inter-Domain Routing Working Group
>>>> of the IETF.
>>>>
>>>>         Title           : Revised Error Handling for BGP UPDATE
>>>> Messages
>>>>         Authors         : Enke Chen
>>>>                           Juniper Networks
>>>>                           Pradosh Mohapatra
>>>>                           Keyur Patel
>>>>     Filename        : draft-ietf-idr-error-handling-09.txt
>>>>     Pages           : 14
>>>>     Date            : 2014-05-19
>>>>
>>>> Abstract:
>>>>    According to the base BGP specification, a BGP speaker that receives
>>>>    an UPDATE message containing a malformed attribute is required to
>>>>    reset the session over which the offending attribute was received.
>>>>    This behavior is undesirable as a session reset would impact not
>>>> only
>>>>    routes with the offending attribute, but also other valid routes
>>>>    exchanged over the session.  This document partially revises the
>>>>    error handling for UPDATE messages, and provides guidelines for the
>>>>    authors of documents defining new attributes.  Finally, it revises
>>>>    the error handling procedures for a number of existing attributes.
>>>>
>>>>    This document updates error handling for RFCs 1997, 4271, 4360,
>>>> 4456,
>>>>    4760 and 5701.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-idr-error-handling-09
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-09
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr