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.
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?
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
