Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)

Dhruv,

thanks for your feedback.

Please see in-line

Le 2019-07-10 à 15:18, Dhruv Dhody a écrit :
> Hi Martin,
> 
> Thanks for your review. See inline...
> 
>   
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Hi,
>>
>> thanks for this document, here are a couple of comments/questions.
>>
>>     The PCEP ASSOC-Type-List TLV is optional.  It MAY be carried within
>>     an OPEN object sent by a PCEP speaker in an Open message to a PCEP
>>     peer so as to indicate the list of supported Association types.
>> This is said twice. (First paragraph of section 4.1) and then in 4.1.1:
>>     A PCEP speaker MAY include an ASSOC-Type-List TLV within an OPEN
>>     object in an Open message sent to a PCEP peer in order to advertise a
>>     set of one or more supported association types.
>>     The use of ASSOC-Type-List TLV is OPTIONAL.
>>
>> It doesn't hurt, but you might want to consider saying this only once.
>> Also I note OPTIONAL vs optional
>>
> [[Dhruv Dhody]] Ack.
> 
> 
>> 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.

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?

> 
>> The PCEP OP-CONF-ASSOC-RANGE TLV is optional.
>> OPTIONAL?
>>
> [[Dhruv Dhody]] Ack.
> 
>> 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?

> 
>> Nits:
>> s/protections LSPs/protection LSPs/
>> s/The Assoc-type MAY appear more than once/A given Assoc-type MAY appear
>> more than once/ s/to uniquely identifying/to uniquely identify/
>>
>>
> [[Dhruv Dhody]] Ack.
>   
> 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
> 
> Thanks!
> Dhruv
> 
>> _______________________________________________
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
> 