Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)

["Alexey Melnikov" <[e-mail]>]

On Thu, Oct 31, 2019, at 1:11 PM, Rifaat Shekh-Yusef wrote:
> Hi Alexey,
> 
> I am fine with Paul's suggestion.
> Are you ok with "32*LHEX"?
Yes!

Thank you,
Alexey
> 
> Regards,
>  Rfaat
> 
> 
> On Thu, Oct 31, 2019 at 7:22 AM Alexey Melnikov <[e-mail]> wrote:
>> __
>> Hi Rifaat,
>> 
>> On Wed, Oct 30, 2019, at 9:50 PM, Rifaat Shekh-Yusef wrote:
>>> Thanks Alexey!
>>> 
>>> I am fine with the first two comments, and will fix these in the coming version of the document.
>>> 
>>> I am not sure I follow the 3rd one. Why do you see the need for a minimum number of hex digits?
>> You do say that the number of hex digits match the hash lenght, so it is probably Ok. However empty value is never valid (and I am worried it might hit some boundary condition bug in implementations), so prohibiting it in ABNF would be the best.
>> 
>> Best Regards,
>> Alexey
>>> 
>>> Regards,
>>>  Rifaat
>>> 
>>> 
>>> 
>>> On Wed, Oct 30, 2019 at 1:16 PM Alexey Melnikov via Datatracker <[e-mail]> wrote:
>>>> Alexey Melnikov has entered the following ballot position for
>>>> draft-ietf-sipcore-digest-scheme-12: No Objection
>>>> 
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> I am agreeing with Alissa's DISCUSS.
>>>> 
>>>> Also, I have a few comments of my own:
>>>> 
>>>> 1) Last para of Section 2.1:
>>>> 
>>>> 2.1. Hash Algorithms
>>>> 
>>>>  A UAS prioritizes which algorithm to use based on the ordering of the
>>>>  challenge header fields in the response it is preparing.
>>>> 
>>>> This looks either wrong or confusing to me. I think you are just saying here
>>>> that the order is decided by the server at this point.
>>>> 
>>>>  That
>>>>  process is specified in section 2.3 and parallels the process used in
>>>>  HTTP specified by [RFC7616].
>>>> 
>>>> So based on the above, my suggested replacement for both sentences:
>>>> 
>>>>  A UAS prioritizes which algorithm to use based on its policy,
>>>>  which is specified in section 2.3 and parallels the process used in
>>>>  HTTP specified by [RFC7616].
>>>> 
>>>> 2) Last para of Section 2.4:
>>>> 
>>>>  If the UAC cannot respond to any of the challenges in the response,
>>>>  then it SHOULD abandon attempts to send the request unless a local
>>>>  policy dictates otherwise.
>>>> 
>>>> Is trying other non Digest algorithms covered by "SHOULD abandon"?
>>>> If yes, maybe you should make this clearer.
>>>> 
>>>>  For example, if the UAC does not have
>>>>  credentials or has stale credentials for any of the realms, the UAC
>>>>  will abandon the request.
>>>> 
>>>> 3) In Section 2.7:
>>>> 
>>>>  request-digest = LDQUOT *LHEX RDQUOT
>>>> 
>>>> This now allows empty value. I suggest you specify a minimum number of hex
>>>> digits allowed in the ABNF. Or at least change "*LHEX" to "2*LHEX".
>>>> 
>>>> 
>>