Dhruv, thanks in return for discussing these comments.
Thanks for the new paragraph, and thanks for pointing me to what I should have found myself. on the unsupported/unknown, it is clearer now. Thanks. -m Le 2019-07-10 à 20:15, Dhruv Dhody a écrit : > Hi Martin, > > Thanks for further discussion, see in-line.. > > <snip> >>> >>> >>>> Sending ASSOC-Type-List TLV is optional but it might be mandatory to send >>>> some to-be-defined Association types. Isn't that somehow conflicting? >>>> >>> [[Dhruv Dhody]] The aim was to say that right now this TLV is optional, but >>> a future association type (say disjoint) can specify that if you want to >>> use *this particular association type* you need to include the TLV. So if >>> an implementation does not support this particular association type, the >>> TLV would be optional, and if it needs to support this, then the TLV >>> becomes mandatory to include. >> >> I understand the aim, but I fail to understand how it doesn't lead to >> conflicting requirements. >> This doc says, the whole TLV is optional. >> A future doc might say: this assoc-type in this TLV is mandatory. >> >> By construction the future doc is thus saying that the TLV is mandatory, >> which conflicts with the base spec. >> >> Couldn't you lay out the path for the future by saying something like: >> * MUST be sent if it contains at least an assoc-type which must be sent >> and MAY NOT be sent otherwise. >> > > [Dhruv]: I agree, I can update the text to say - > > Association type (to be defined in other documents) can specify if > the association type advertisement is mandatory for it. Thus, the > ASSOC-Type-List TLV MUST be included if at least one mandatory > association type needs to be advertised and the ASSOC-Type-List TLV > MAY be included otherwise. > > I used MAY, as MAY NOT is not RFC 2119 keyword. > >> >> As a side question, sorry I didn't go back to the doc, but how should >> the systems behave in the case where there are two assoc types: one >> mandatory and the other not. >> MUST the system advertise both in the list or can it only advertise the >> mandatory one? And how will the receiver treat that latter case? I'm >> asking because I think you cover the case of not sending the whole TLV >> and then the receiver MUST interpret that as an absence of information >> on the list of supported Association types (rather than the Association >> type is not supported), but if it receives the TLV without the assoc >> type, should it still interpret it as an absence of info or as not >> supported? >> > > We have this text in the I-D that covers these conditions - > > For an association type that specifies > that the advertisement is mandatory, a missing Assoc-type in the > ASSOC-Type-List TLV (or missing ASSOC-Type-List TLV) is to be > interpreted as the association type is not supported by the PCEP > speaker. > > The absence of the ASSOC-Type-List TLV in an OPEN object MUST be > interpreted as an absence of information on the list of supported > Association types (rather than the Association type is not > supported). In this case, the PCEP speaker could still use the > ASSOCIATION object: if the peer does not support the association, it > will react as per the procedure described in Section 6.4. > > In case the use of the ASSOC-Type-List TLV is triggered by support > for a mandatory association type, then it is RECOMMENDED that the > PCEP implementation include all supported Association types > (including optional) to ease the operations of the PCEP peer. > > <snip> >>> >>>> Could you clarify the difference between a PCEP speaker does not recognize >>>> the ASSOCIATION object and a PCE peer is ... unable to process the >>>> ASSOCIATION I see that the errors thrown are different. >>>> >>> [[Dhruv Dhody]] The difference is between ASSOCIATION Object being unknown >>> (former) and Object being known *but* not supported/processed (latter). >> >> That doesn't really clarify. What is the difference between unknown and >> not supported? > > Unknown - I parse the PCEP object header, and find an object-type, I > dont know what this object type means and it is unknown. > Not Supported - I parse the PCEP object header, and find an > object-type that i am aware of but for some reason do not support. > This could be because of feature being disabled via configuration for > instance. > > Note that these errors are defined in PCEP since its inception in RFC 5440. > > Last Commit: > https://github.com/dhruvdhody-huawei/ietf/commit/a00b161661a334d800bab99dedbd2012e3951651 > > Please let me know if any further change is needed. > > Thanks! > Dhruv > > <snip> >>> Working Copy: >>> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt >>> Diff: >>> https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-association-group-09&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-10.txt > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
