Behcet: Good question you raised here. I think the device used by this draft is not limited to IoT devices, It is also applicable to other terminal devices in the home network or enterprise network scenarios. Maybe this is one of reason why this draft doesn’t directly reference RFC7228 for the “device” used in this draft. Happy to hear authors’ opinion on this question as well.
-Qin 发件人: Behcet Sarikaya [mailto:[email protected]] 发送时间: 2025年6月30日 10:13 收件人: Qin Wu <[email protected]> 抄送: [email protected]; [email protected]; [email protected] 主题: Re: [Iot-directorate] draft-ietf-anima-brski-cloud-15 telechat Iotdir review Hi, I received this mail because I am an IoT Dir member. I read Qin's review and subsequent conversation. Why am I writing this mail? Let me explain. I see, in the draft, frequent use of the word "device". I think that it refers to an IoT device. But then I see in the Introduction, I think par. 6, that it refers to a SIP Phone. I don't know what a SIP phone refers to and I looked at RFC 3261 which is given as a reference to SIP phone and I learned that RFC 3261 does actually refer to the SIP protocol. I just would like to ask what does the device refer to and does that have any relevance to RFC 7228. If this is explained I would have no issue with the security related aspects/contributions of the draft which are designed by people whose security area expertise I deeply respect. Behcet On Sat, Jun 28, 2025 at 7:44 AM Qin Wu via Datatracker <[email protected]<mailto:[email protected]>> wrote: Document: draft-ietf-anima-brski-cloud Title: BRSKI Cloud Registrar Reviewer: Qin Wu Review result: Ready with Nits I am the assigned IoT Directorate reviewer for this draft. The Directorate aims to review IETF documents related with IoT (Internet of Things). Please treat these comments just like any other last call comments. For more information, please see https://datatracker.ietf.org/group/iotdir/about/ Thank you editors for taking into consideration the feedback in my early review, specifically. The latest version is in good shape and easy to digest. A few more editorial comments and suggestions as follows: 1. Can you distinguish term definitions and abbreviations in the terminology section, e.g., VAR is frequent occurred abbreviation, it will be nice to introduce abbreviation separately in the terminology section 1.1. 2. Section 1.2 said: " There are DHCP options that a network operator can use to configure devices such as a VoIP phone. DHCP options 66, 150 (TFTP/HTTP server names), option 120 (SIP Server), or even option 157 (Certificate Provisioning) " Can you add reference to new introduced DHCP options? 3. Can you add a legend for "VR-sign(N)"? Also there are no text in section 2 to explain "VR-sign(N)". 4. Section 5 said: "In the event of a merger between two companies, then the mechanism that is described in section 7.2 MAY be applicable. " The mechanism in section 7.2 May be applicable for what??, It seems not complete. 5. Section 7.1 said: " The Provisional TLS connection does not do [RFC9525], Section 6.3 DNS-ID verification at the beginning of the connection, so a forced redirection to a captive portal system will not be detected. " Are you saying Provisional TLS Connection does not do DNS-ID Verification, if yes, suggest to move "[RFC9525] Section 6.3" after DNS-ID verification. 6. Section 7.1 said: " It is RECOMMENDED therefore that the Pledge look for [RFC8910] attributes in DHCP, and if present, use the [RFC8908] API to learn if it is captive. " NEW TEXT: " It is RECOMMENDED therefore that the Pledge look for Captive-Portal Identification attributes [RFC8910] in DHCP, and if present, use the Captive-Portal API [RFC8908] to learn if it is captive. " -- Iot-directorate mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
