A SIP Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-sip-21

[Ballot comment]
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.

On page 10:

  Inclusion of a  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?

[Ballot comment]
I'm balloting "yes" because I want to see this move forward, but I have a number of comments and questions:

Substantive:

- Figure 1: It might be helpful to show the R-URI in the INVITE.

- 1, 2nd to last paragraph: Please add a citation for GRUU.

- 3.3, 7th paragraph from end: "any peer SHOULD verify
  that the AOR of the request is a valid Resource Name with respect to
  its domain name "
How does that differ from the MUST in the first bullet, below? Also, does SIP over reload support phone numbers? If so, it would be good to include some discussion about how phone numbers fit into the domain scheme. If no, then please say so explicitly.

-3.3, 3rd and 4th paragraph from end:
What certificate? (Probably covered in RELOAD, but a comment here would be helpful.)

- 3.4, first paragraph:
The "MAY" looks like a statement of fact. I suggest "might"

- 3.4, fourth paragraph:
That seems to say that "enable=false" means the restrictions are enabled. Is that the intent?

- 4.1, 2nd and 3rd paragraphs from end:
Does that mean normal SIP procedures should be used if no overlay is found for the domain, or that normal SIP procedures can be used instead of checking for other overlays?

What about the case where the domain is supported by the overlay, but the AOR is not found? Should the caller check for other overlays, or switch to standard SIP?

- 5.1, 2nd paragraph:
Are SIPS over reload connections assumed to be e2e encrypted? The last sentence says that ordinary SIPS requires e2e encryption, which is simply not true.
What are "client links"?

- 5.1, 3rd paragraph, last sentence:
does "redirect its communication path" mean redirect to classic SIP?

- 6, first paragraph: "Globally Routable User Agent URIs (GRUUs) [RFC5627] have been
  designed to allow direct routing without the indirection of a SIP
  proxy function. "
That’s not really true. 5627  section 3.4 talks about using the proxy to dereference a gruu.

- 8.1, first paragraph: "Hence no
  extra burden is introduced for RELOAD peers beyond loads already
  present in the base protocol."
What about from when a caller chooses to switch to conventional SIP to reach a callee with a domain not supported by the overlay?

- 8.2.4: Can you cite something for these methods that exist?

Editorial:

- IDNits has some comments marking code blocks. The data structure in 3.2 seems to qualify.

-2 : It would have been useful to mention that you are intentionally dropping the AoR schemes back at the first AoR example.
Otherwise SIP people are going to be confused until they find the comment 5 pages in.

- 3.1, first paragraph: "a UA registers its AOR and location"
technically, the user’s AOR and the UAs network location.

- 3.2, 3rd bullet in first bullet list:
It's a bit premature to use the term Callee. Perhaps Registrant?

- 4.2, step 3:
What is an "external AoR"?

- Appendix A: Why is this not in the main body?

[Ballot comment]

- 5.1: I guess it's too late to ask, but I'll ask
anyway, just in case this hasn't yet been implemented
and it's not too late... I can see why you want to
support SIP URIs and can't e.g. only support SIPS URIs
here.  But in supporting SIP URIs couldn't you have
taken an opportunistic security approach to using TLS
and e.g. maybe treated a SIP URI as if it's a SIPS URI
except for the certificate validation step? I do get
that that might restrict re-use of unmodified SIPS
stacks but maybe that'd be ok in this context. Any
chance of considering that or is it too late or a case
where there's not enough energy/interest?  (EIther form
of "no" is a very reasonable answer.)

- Just out of curiosity, are folks deploying this
anywhere?

[Ballot comment]
This was a bit confusing to me.

  AOR domain not supported by overlay?  If the domain part of the AOR
      is not supported in the current overlay, the user SHOULD query the
      DNS (or other discovery services at hand) to search for an
      alternative overlay that services the AOR under request.
      Alternatively, standard SIP procedures for contacting the callee
      SHOULD be used.
     
If you don't query the DNS (or other discovery services), and you don't use standard SIP procedures, are there any other choices? With both of these being SHOULDs, a conformant implementation might not do either of them. Is that expected?

If you need this to be RFC 2119 language, I'm guessing this would be "MUST either do X or Y", but I'm not sure it needs to be RFC 2119.

If you really do need two alternative SHOULDs, it's not required to explain why a SHOULD is not a MUST, but since the goal is that an implementer is making an informed choice, helping the implementer understand why one might not want to do what one SHOULD do is usually helpful.

I think that

  A callee MAY choose to listen on both
  SIP and SIPS ports and accept calls from either SIP schemes, or
  select a single one.
 
is using "SIP schemes" generically, but this might be clearer if you just said "either scheme".

I'm not on top of SIPS these days, but I didn't think

  SIPS requires end-to-end protection that may include client links and
  endpoint certificates.
 
was "end-to-end protection". Is it? I thought that it was protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP?

Sorry if I'm confused (and the SIP Forum will be thrilled to hear this, if I'm just confused).

I can figure out what "fork explosion" and "fork bomb" are, but are these terms in common usage in the SIP community? Is there a definition or reference for them?

[Ballot comment]
Mentioning "opaque string" in the terminology section would be good.

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.

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. Thank you for adding text that %-encoding should be decoded, but I also think this should point to RFC 3986.

On page 10:

  Inclusion of a  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?

[Ballot comment]
The privacy issues text in the security consideration section sounds not very convincing:

8.2.4.  Privacy Issues

  All RELOAD SIP registration data is visible to all nodes in the
  overlay.  Methods of providing location and identity privacy are
  still being studied.  Location privacy can be gained from using
  anonymous GRUUs.

Can you give more details or a reference regarding the methods that are still under study?

[Ballot 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.

Also, the first reference to rfc822Name (earlier in the document) needs a normative reference to RFC 5280.

[Ballot 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".

What does "opaque string" means here? You still need to define syntax of the field.

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.

On page 10:

  Inclusion of a  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?

  The  element serves as a container for zero to
  multiple  sub-elements.  A  element MAY be present
  if the "enable" attribute of its parent element is set to true.  Each
    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?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-p2psip-sip-17.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the RELOAD Data Kind-ID subregistry of the REsource LOcation And Discovery (RELOAD) registry located at:

https://www.iana.org/assignments/reload/

a single new code point will be registered as follows:

Kind-ID: 0x1
Kind: SIP-REGISTRATION
Reference: [ RFC-to-be ]

Second, in ns subregistry of the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

a new URI will be registered as follows:

ID: p2p:config-base:sip
URI: urn:ietf:params:xml:ns:p2p:config-base:sip
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-p2psip-sip@ietf.org, alissa@cooperw.in, p2psip@ietf.org, cjbc@it.uc3m.es, p2psip-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A SIP Usage for RELOAD) to Proposed Standard


The IESG has received a request from the Peer-to-Peer Session Initiation
Protocol WG (p2psip) to consider the following document:
- 'A SIP Usage for RELOAD'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-04-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a SIP Usage for REsource LOcation And Discovery
  (RELOAD).  The SIP Usage provides the functionality of a SIP proxy or
  registrar in a fully-distributed system and includes a lookup service
  for Address of Records (AORs) stored in the overlay.  It also defines
  Globally Routable User Agent Uris (GRUUs) that allow the
  registrations to map an AOR to a specific node reachable through the
  overlay.  After such initial contact of a peer, the AppAttach method
  is used to establish a direct connection between nodes through which
  SIP messages are exchanged.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ballot/


No IPR declarations have been submitted directly on this I-D.

A SIP Usage for RELOAD (draft-ietf-p2psip-sip-16)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

The document has received community review, and appears to enjoy enough
community interest to be considered valuable. It defines a SIP usage for
RFC6940, which also has the status of Proposed Standard.

Is this type of RFC indicated in the title page header?

Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

This document defines a SIP Usage for RELOAD (RFC6940). This SIP Usage provides
the functionality of a SIP proxy or registrar in a fully-distributed system and
includes a lookup service for Address of Records (AORs) stored in the overlay.
The document also defines Globally Routable User Agent URIs (GRUUs) that allow
the registrations to map an AOR to a specific node reachable through the
overlay.  After such initial contact of a peer, a direct connection between
nodes (to exchange SIP messages) can be established using the AppAttach method.

Working Group Summary:

The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd has personally performed an additional review of the
document. The Document Shepherd believes the document is ready for forwarding
to IESG for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breadth of these
reviews.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

The Document Shepherd has no such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There is WG consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

The idnits tool returns 0 errors, 3 warnings and 4 comments. It contains a
disclaimer for pre-RFC5378 work, but the authors mentioned that the document
borrowed text from pre-5378 RFCs and tgey feel that the disclaimer cannot be removed.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

The document meets the review criteria. The document shepherd section 6
(about GRUUs) and found the use of URIs consistent.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The document request to register a new code point in the "RELOAD Data Kind-ID"
(RFC6940) and to register a new URI in the IETF XML registry defined in RFC3688.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

None.

A SIP Usage for RELOAD (draft-ietf-p2psip-sip-16)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

The document has received community review, and appears to enjoy enough
community interest to be considered valuable. It defines a SIP usage for
RFC6940, which also has the status of Proposed Standard.

Is this type of RFC indicated in the title page header?

Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

This document defines a SIP Usage for RELOAD (RFC6940). This SIP Usage provides
the functionality of a SIP proxy or registrar in a fully-distributed system and
includes a lookup service for Address of Records (AORs) stored in the overlay.
The document also defines Globally Routable User Agent URIs (GRUUs) that allow
the registrations to map an AOR to a specific node reachable through the
overlay.  After such initial contact of a peer, a direct connection between
nodes (to exchange SIP messages) can be established using the AppAttach method.

Working Group Summary:

The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd has personally performed an additional review of the
document. The Document Shepherd believes the document is ready for forwarding
to IESG for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breadth of these
reviews.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

The Document Shepherd has no such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There is WG consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

The idnits tool returns 0 errors, 3 warnings and 4 comments. It contains a
disclaimer for pre-RFC5378 work, but the authors mentioned that the document
borrowed text from pre-5378 RFCs.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

The document meets the review criteria.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The document request to register a new code point in the "RELOAD Data Kind-ID"
(RFC6940) and to register a new URI in the IETF XML registry defined in RFC3688.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

None.