Hi Thomas, > On 19 Apr 2016, at 18:20, Thomas C. Schmidt <[email protected]> wrote: > > Hi Alexey, > > please see the two open answers inline. > >> On 18.04.2016 09:37, Alexey Melnikov wrote: >> 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. > > O.K. - we added.
Thank you. >>> >>>> 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? > > Actually, in the terminology section is an explicit mentioning of the AOR > from RFC 3261 and how to use it here. From my understanding, any additional > marking might rather generate confusion than clarity - in particular since an > understanding of SIP terminology is rather natural in the context of this > document ("SIP Usage"). > > Do you agree? Works for me. > Best, > Thomas > >>> >>>> 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! > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
