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]> 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] > To unsubscribe send an email to [email protected] >
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
