Hi Thomas, > On 17 Apr 2016, at 22:07, Thomas C. Schmidt <[email protected]> wrote: > > Hi Alexey, > > many thanks for your careful review. Please see inline: > >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I will move to No Objection once my comments are discussed. They should >> be easy to address. >> >> In Section 7: >> >> Access Control USER-NODE-MATCH. Note that this matches the SIP >> AOR >> against the rfc822Name in the X509v3 certificate. The rfc822Name >> does not include the scheme so that the "sip:" prefix needs to be >> removed from the SIP AOR before matching. >> >> In general the advice of stripping "sip:" is misleading, because URIs >> might have %-encoding, which is not present in rfc822Name, which is an >> email address. I think adding text that %-encoding should be decoded >> would be a good idea. > > Thanks for pointing at this: We added > > "Escaped characters ('%' encoding) in the SIP AOR also need to be decoded > prior to matching."
Adding a reference to RFC 3986 would be good here. > >> Also, the first reference to rfc822Name (earlier in the document) needs a >> normative reference to RFC 5280. > > We added the ref. in Section 2. > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In 3.2: >> >> If the registration is of type "sip_registration_uri", then the >> contents are an opaque string containing the AOR as specified in >> Section 2. >> >> Is the reference correct? Section 2 is "Terminology". > > Nope, this is a historic editing mistake -> removed. > >> What does "opaque string" means here? You still need to define syntax of >> the field. > > "opaque string" is the appropriate (single valued) data type of RELOAD (see > https://tools.ietf.org/html/rfc6940#section-7.2). Further specifications are > given as "the AOR". Ok. Maybe put in quotes or point this out in the terminology section? > >> In 3.3: >> >> Before a Store is permitted, the storing peer MUST check that: >> >> o The AOR of the request is a valid Resource Name with respect to >> the namespaces defined in the overlay configuration document. >> >> o The certificate contains a username that is a SIP AOR which hashes >> to the Resource-ID it is being stored at. >> >> o The certificate contains a Node-ID that is the same as the >> dictionary key it is being stored at. >> >> Is there a document that defines how exactly a username and a Node-ID can >> be represented in an X.509 certificate? If yes, adding a normative >> reference here would be useful. If not, adding specific details here >> would be useful. > > Username is a SIP AOR as specified in RFC 3261 (this is normatively > referenced in Section 2). A Node-ID is an Overlay Hash, which is defined in > RFC 6940 (also normatively referenced in Section 2). Ok. > >> On page 10: >> >> Inclusion of a <domain-restrictions> element in an overlay >> configuration document is OPTIONAL. If the element is not included, >> the default behavior is to accept any AOR. If the element is >> included and the "enable" attribute is not set or set to false, the >> overlay MUST only accept AORs that match the domain name of the >> overlay. >> >> What happens if "enable" is false/unspecified and patter subelements are >> included? Are they ignored? > > According to the writing, this means that > > " the > overlay MUST only accept AORs that match the domain name of the > overlay." > > The case you are describing is an inconsistently extended overlay > configuration document. Hence, this spec tells to ignore inconsistent > extensions (isolated pattern subelements), which I believe makes sense. Any > counter-arguments? No, this sounds entirely sensible. > >> The <domain-restrictions> element serves as a container for zero to >> multiple <pattern> sub-elements. A <pattern> element MAY be present >> if the "enable" attribute of its parent element is set to true. Each >> <pattern> element defines a pattern for constructing admissible >> resource names. It is of type xsd:string and interpreted as a >> regular expression according to "POSIX Extended Regular Expression" >> (see the specifications in [IEEE-Posix]). >> >> This repeats part of the second paragraph of the same section. Is this >> repetition needed? > > Oopsi - no. This is an editing mistake, most likely from copying a block > while revising text. It is removed now. > > Thanks again for finding these lapses! > > We revise and submit. Thank you! _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
