[sipcore] Re: Éric Vyncke's Discuss on draft-ietf-sipcore-callinfo-rcd-17: (with DISCUSS and COMMENT)

[Richard Shockey <[e-mail]>]

 

Please folks ..pretty please.  We are actually trying to deploy this stuff.

 

 

 

https://www.sipforum.org/news-events/branded-calling-summit-overview/schedule/

 

 

 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN [phone]

 

 

From: "Eric Vyncke (evyncke)" <evyncke=[e-mail]>
Date: Tuesday, April 15, 2025 at 4:00 PM
To: Chris Wendt <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [sipcore] Re: Éric Vyncke's Discuss on draft-ietf-sipcore-callinfo-rcd-17: (with DISCUSS and COMMENT)

 

Hello Chris,

 

The -18 addresses indeed all my concerns, as you may have seen: I have cleared my DISCUSS.

 

I sincerely think that the document has improved with your edits.

 

Regards

 

-éric

 

From: Chris Wendt <[e-mail]>
Date: Tuesday, 15 April 2025 at 13:37
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-sipcore-callinfo-rcd-17: (with DISCUSS and COMMENT)

Hi Eric,

 

The -18 has been posted. https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-18

 

Thanks!!

 

-Chris

 

On Apr 15, 2025, at 12:50 AM, Eric Vyncke (evyncke) <[e-mail]> wrote:

 

Hello Chris,

 

Thanks[1] for your quick reply, the proposed fixed for my DISCUSS is correct (I told you it was easy to fix 😊 ). I put some more comments on EVY>.

 

Anyway, once a -18 is submitted, then I am clearing my DISCUSS.

 

Regards

 

-éric

 

[1] and also for using the É in my first name 😊

 

From: Chris Wendt <[e-mail]>
Date: Tuesday, 15 April 2025 at 02:43
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail]<[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-sipcore-callinfo-rcd-17: (with DISCUSS and COMMENT)

Hi Éric, 

Thanks for the comprehensive review and improvement suggestions, comments inline.  I have a -18 version ready to submit with aggregated updates from multiple reviews coming in recently.  Please let me know if i’ve addressed your DISCUSS.

-Chris

> On Apr 14, 2025, at 11:23 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-sipcore-callinfo-rcd-17: Discuss
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-sipcore-callinfo-rcd-17
> CC @evyncke
> 
> Thank you for the work put into this document. It is really clear and easy to
> understand even if it would have been better to have
> draft-ietf-stir-passport-rcd in the same IESG telechat.
> 
> Please find below one blocking DISCUSS point (easy to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only for
> my own education), and one nit.
> 
> Special thanks to Jean Mahoney for the shepherd's write-up including the WG
> consensus *but it lacks* the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## DISCUSS (blocking)
> 
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is just a request to have a discussion on the following topics:
> 
> ### Section 10.7.1
> 
> Hopefully, I am wrong but there is no `Raleigh/North America` time zone...

Ha, yes fixed to "America/New_York”  it actually came from RFC6350 example.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> ## COMMENTS (non-blocking)
> 
> ### Abstract
> 
> s/This document *describes* a usage/This document *specifies* a usage/ as it is
> PS

Fixed

> 
> ### Section 1
> 
> `it is an unsecured field` is rather vague, should it rather be 'authenticated'
> or 'trustworthy' ?

Fixed with:
s/it is an unsecured field that is not commonly trusted and is often replaced or ignored/it is a field that is not commonly trusted and is often replaced or ignored

> 
> `To allow calling parties to initiate, ... for incoming calls` seems weird ;-)

Agree, changed to "This document defines usage of the SIP Call-Info header field {{RFC3261}} allowing called parties to receive a more comprehensive and extensible set of Rich Call Data (RCD) for incoming calls. It specifically defines specific usage of the Call-Info header field, a new parameter ..."

> 
> Without being an expert in SIP and having still to read the rest of this I-D, I
> wonder whether 'translate' means 'between human languages' or something else.
> Perhaps worth not using 'translate' or being more specific ?

Agree, The first two instances of “translate" i replaced “translate” with “protect”.  The last i simply removed translate.

"In order to properly protect and communicate some of the authenticated and trusted properties…”
"These parameters help protect RCD information that had been sent via a SIP network…”
"The verification procedures include the successful verification of the "rcd" claims and can be correspondingly represented in the Call-Info header field via these new parameters."

> 
> ### Section 3
> 
> Suggest to be consistent with the use of single and double quotes, especially
> in the first paragraph.

I believe it is consistent with what is conventionally used for string tokens vs strings used as strings.  At least that is the logic.

 

EVY> Thanks for checking, all is good



> 
> ### Section 4
> 
> s/the Call-Info header field to be compatible and compl*i*mentary/the Call-Info
> header field to be compatible and compl*e*mentary/ ?

Correct, fixed.

> 
> ### Section 5
> 
> When using 'cid' scheme, how is it secured & made trustworthy ?

The intention of this spec is to facilitate the standard use of call-info over UNI “trusted” interface.  Stir exists to sign data and attribute it to the signing party over untrusted network to network interface.  So, the answer is that there is no mechanism intended to make the ‘cid’ scheme specifically secure or trustworthy. 

 

EVY> understood, perhaps worth explaining also in the I-D ? Up to the authors



> 
> I would have expected an exhaustive list in a PS rather than a rather vague
> `The fields like "fn", "photo", or "logo"`.

This was discussed how prescriptive to be about industry usage of jcard properties for specific purposes, like what is the difference between usage of logos vs photos, but we left that to profile specifications to provide guidance in the future.  For this paragraph, it refers to having both “icon” defined in RFC3261 and “jcard” with any of the similar photo/logo types of images included to say that you must not try using both and expect the user device to have deterministic behavior.

> 
> You made my day with `MI6;Q Branch Spy Gadgets` :-) :-)

Glad you like it :)

> 
> ### Section 7
> 
> Should 'NNI' be expanded in `via an NNI`?

It was expanded previously in the document

 

EVY> and I failed to spot it, sorry


> 
> I must have missed something, but the "verified=true" seems a little easy to
> forge. Or if sent by the last SIP proxy/forwarder (like a DNSSEC validator),
> then should there be some specifications around this restriction ?

It is intended to be an indicator in a trusted UNI relationship that the data was sent and verified from a source that was signed by stir versus other sources of information.  That is all it is intended to indicate in case the user agent wants to indicate (with a green check mark or some visual indicator) that it was network verified.  This is another example of something that is a tool available for further real-world profile usage.

EVY> fine for me, but I think readers would appreciate some justifications (like the above)


> 
> ### Section 10
> 
> In `which every implementation of this specification should adhere` what about
> a BCP14 "SHOULD" ?

Probably yes, but I’m a little worried about too many logical changes to make SHOULD work.

> 
> ### Section 10.1
> 
> Isn't `(unless updated by any future extensions of this specification)` obvious
> ? I.e., let's remove it.

Got a similar comment before, will remove.

> 
> `The authors do not believe` after IETF Last Call, the belief is probably 'The
> IETF'.

Good point.  Changed to "There is not anticipated to be need for …"

> 
> ### Section 10.2
> 
> Possibly because English is not my primary language, but suggest rewriting
> `some guidance current to the authoring of this document` to use 'at the time
> of writing' or 'in 2025'.

Changed to "this document provides guidance at the time of writing that …"

> 
> Who is the "we" in this section ? The authors ? The WG ? The IETF community ?
> Let's try to be specific.

Changed “we suggest” to "this specification suggests …"

> 
> There are references to PNG, JPG but none for mp3, mp4... moreover the given
> reference for .wav is about the code string and not the actual codec.

This was suggested reference in previous reviews.  mp3 and particularly mp4 references could be difficult and problematic to specify given the potential rathole of ways to define those file formats and media types, so i’m referring to them a bit generically on purpose.

 

EVY> understood, still feeling sad about it but I have no solution to propose



> 
> ## NITS (non-blocking / cosmetic)
> 
> ### Section 6
> 
> s/for display to an end user/for display to an end*-*user/ ?
> 
> 
Fixed

> 

 

_______________________________________________ sipcore mailing list -- [e-mail] To unsubscribe send an email to [e-mail]