Re: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT)

Adam Roach <adam@nostrum.com> Fri, 01 March 2019 21:47 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECE1130F2C; Fri, 1 Mar 2019 13:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSpRLRz9Lq5I; Fri, 1 Mar 2019 13:47:09 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15984130F3F; Fri, 1 Mar 2019 13:47:09 -0800 (PST)
Received: from Orochi.local (rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21Lkxca015596 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 15:47:01 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551476823; bh=6Kw04wI6EPGkMnVpXVIq6UOQExZAM7a5AdXzExTIq3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oDtZDCNS2WnjUd7xucRh6qjI5NzIGvKYKWLd3LFbBbGA6gIcv2IgLTKq1V2yfhYOB 6Em/EH6pxIKwGxLw7/vf5otEz7zf/rrOADZf8HKYBCZQOBI9FGWM9/LfyofSrZ/011 N94uT6/svghn7HP6jEVKAJZlsFkLknBbpt0rxlpQ=
X-Authentication-Warning: raven.nostrum.com: Host rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58] claimed to be Orochi.local
To: Christer Holmberg <christer.holmberg@ericsson.com>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-sipcore-sip-push@ietf.org" <draft-ietf-sipcore-sip-push@ietf.org>, Brian Rosen <br@brianrosen.net>, "sipcore-chairs@ietf.org" <sipcore-chairs@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>
References: <155146051337.6186.9467252084775433080.idtracker@ietfa.amsl.com> <HE1PR07MB31616FC1F5E8B496C5C14A9F93760@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <377b379d-3747-3748-694d-2c3fa621483b@nostrum.com>
Date: Fri, 01 Mar 2019 15:46:59 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2
MIME-Version: 1.0
In-Reply-To: <HE1PR07MB31616FC1F5E8B496C5C14A9F93760@HE1PR07MB3161.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------9D7DCED0AAB74BEBDD290DFC"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/NMLWcJOyidroruXOljNeMB872vw>
Subject: Re: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 21:47:23 -0000

HI! I apologize if it was unclear from my preamble, but the original 
comments were only included because I wanted the document ballot to 
retain them for historical purposes. No reply was necessary.

/a

On 3/1/19 15:31, Christer Holmberg wrote:
>
> Hi Adam,
>
>
> Thank You!
>
>
> Your issues have been addressed. In this reply I more or less 
> copy/paste what I said in my previous reply to your review, and give 
> some extra details on how issues were solved.
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
> ----------------------------------------------------------------------
>
> >It's nice that this document has considered the impact of inbound mid-dialog
> >messages in long-lived dialogs. However, it appears to have a major 
> hole in it:
> >handing of outbound messages for the purpose of maintaining 
> soft-state in those
> >dialogs isn't handled correctly.
> >
> >In particular: networks that deploy this mechanism will cause SUBSCRIBE
> >dialogs to time out and be destroyed while they are still in use.
> >Additionally, if RFC 4028 (session timers) is negotiated, then INVITE 
> dialogs
> >will suffer the same fate.
> >
> >I can think of a couple of ways for these situations to be handled, 
> but they
> >need explicit text in the document.
> >
> >One approach would be to specify that the User Agent selects its 
> requested
> >"Expires" value in its registration to be the smallest value before 
> its set of
> >subscriptions and session timers needs to be refreshed. This would 
> cause a push
> >notification to happen to prevent registration timeout, and the 
> client could
> >refresh the other soft state at that time. Complications arise if the 
> registrar
> >responds with a 483 (Interval too Brief), and we'd need to find a 
> solution for
> >that.
> >
> >Another approach would be for the clients to refresh all soft state 
> whenever
> >they send a registration, and set the timeout for that soft state to 
> be equal to
> >or greater than the registration timeout. A complication could arise 
> if the
> >notifier or the peer in an invite dialog shortens the requested time, 
> and we'd
> >need to find a solution for that.
> >
> >A third approach would be getting the proxy involved in some way -- 
> either by
> >requiring it to observe subscription and session timer timeouts and 
> requiring it
> >to send push notifications prior to their expiration, or by an explicit
> >communication between the UA and the proxy that indicates when the 
> next push
> >notification should be scheduled. If the latter approach is taken, I 
> would
> >suggest that it needs to be taken for REGISTER messages as well.
> >
> >I really don't think this mechanism is feasibly deployable without a 
> solution to
> >this problem.
>
> This has been addressed, and the text in section 4.1.1 now says:
>  "This specification does not define a mechanism to explicitly request 
>    push notifications from the SIP network for usages other than    
> triggering binding-refresh REGISTER requests (e.g., for sending    
> periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does 
>    it describe how to distinguish push notifications associated with 
>    such usages from the push notifications used to trigger binding-    
> refresh REGISTER requests.  If a SIP UA wants to use push    
> notifications for other usages, the UA can perform actions associated 
>    with such usages (in addition to sending a binding-refresh REGISTER 
>    request) whenever it receives a push notification by using the same 
>    refresh interval that is used for the binding-refreshes."
>
>
> ---------------------------------------------------------------------------
>
> §4.1:
>
> >  For privacy and security reasons, the UA MUST NOT include the SIP URI
> >  parameters defined in this document in non-REGISTER request, to
> >  prevent the PNS information associated with the UA from reaching the
> >  remote peer.
> >
> >This seems to ignore the availability of Contact URI parameters via 
> RFC 3680
> >subscriptions. This would seem to impose a requirement on Registrars 
> to strip
> >this information before making it available to any other party (which, in
> >turn, requires that the system have explicit Registrar *and* Proxy 
> support).
> >As far as I can tell, the system so far has not required explicit 
> proxy support
> >(and there's certainly no mechanism built-in that ensures that a 
> proxy has any
> >special handling regarding this mechanism).
> >
> >If the PNS information is sensitive, and cannot be allowed to leak out to
> >other users, then we need some way to ensure the registrar has provided
> >positive confirmation that it will not do so before allowing it to 
> come into
> >possession of them.
>
> This has been addressed, and the text now says:
>  "For privacy and security reasons, a UA MUST NOT insert the SIP URI 
>    parameters (except for the pn-purr parameter) defined in this    
> specification in non-REGISTER request in order to prevent the PNS    
> information associated with the UA from reaching the remote peer.    
> For example, the UA MUST NOT insert the pn-prid SIP URI parameter in 
>    the Contact header field URI of an INVITE request.  REGISTER 
> requests    will not reach the remote peer, as they will be terminated 
> by the    registrar of the UA.  However, the registrar MUST still 
> ensure that    the parameters are not sent to other users, e.g., using 
> the SIP event    package for registrations mechanism [RFC3680].  See 
> Section 13 for    more information."
> Section 13 (Security Considerations) contains the following text:
> "Operators MUST ensure that the PNS-related SIP URI parameters    
> conveyed by a user in the Contact URI of a REGISTER request are not    
> sent to other users, or to non-trusted network entities.  One way to 
>    convey contact information is by using the the SIP event package 
> for    registrations mechanism [RFC3680].  [RFC3680] defines generic 
>    security considerations for the SIP event package for 
> registrations.    As the PNS-related SIP URI parameters conveyed in 
> the REGISTER    request contain sensitive information, operators that 
> support the    event package MUST ensure that event package 
> subscriptions are    properly authenticated and authorized, and that 
> the SIP URI    parameters are not inserted in event notifications sent 
> to other    users, or to non-trusted network entities."
>
> ---------------------------------------------------------------------------
>
> §4.2:
>
> >  The UA can do so by only including the pn-provider
> >  SIP URI parameter in the SIP Contact header field URI of the REGISTER
> >  request, but without including the pn-prid SIP URI parameter.
> >
> >Unless I'm mistaken, this is a barrier to interoperation.
> >
> >It's not 100% clear, but I suspect the intended implication is that the
> >pn-provider parameter here will contain a single value? The syntax of the
> >parameter certainly seems to imply that. This seems to be a pretty big
> >problem, since it presupposes that the client will know which PNSes 
> the Proxy
> >supports.  Consider, for example, an iOS client that can use any of 
> RFC 8030,
> >FCM, and APN (cf 
> https://firebase.google.com/docs/cloud-messaging/ios/client).
> >If the client doesn't know a priori what the proxy supports (and this 
> entire
> >section only makes sense if that's true), then it won't know which of 
> those
> >three services to indicate in its REGISTER request. If it guesses 
> wrong, this
> >mechanism simply fails.
> >
> >I think you need a different discovery mechanism here -- either have 
> one that
> >has the client offering multiple PNS protocols and the proxy 
> responding with
> >one, or have one in which the proxy indicates all of its supported 
> services in
> >a response, and the client chooses one to use in its next REGISTER 
> message.
>
> This has been addressed in section 4.1.5 (Query Network PNS 
> Capabilities). The UA can now
> choose to not include the pn-provider parameter, in which case the 
> network will return all
> PNS protocols supported.
>
> ---------------------------------------------------------------------------
>
> >Figure 1:
> >
> >This diagram includes both a ladder diagram and an example REGISTER 
> message.
> >While both of these are useful at this point in the document, neither 
> of them is
> >an "Architecture," and they're really two different things. I suggest 
> breaking
> >this into two Figures, entitled "Typical Information Flow" and 
> "Example REGISTER
> >Message" (or similar), respectively.
>
> This has been addressed as suggested in Section 1 (Introduction).
>
> ---------------------------------------------------------------------------
> *
> §4.1:
>
> >  As long as the UA wants to receive push notifications (requested by
> >  the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
> >  (if required for the specific PNS provider) SIP URI parameter in each
> >  binding-refresh REGISTER request.
> >
> >Please be clear that these parameters appear in the Contact URI.
>
> Eventhough the text above does no longer exist, it has now been 
> generally clarified that the parameters appear in the Contact URI.
>
> (I did note a bug in section 4.1.2. I says "UA MUST include", but it 
> shall be "UA MUST NOT include")
>
> ---------------------------------------------------------------------------
>
> §5.2:
>
> >  In order to request push notifications towards a SIP UA that will
> >  trigger the UA to send binding-refresh SIP REGISTER requests, the SIP
> >  proxy needs to have information about when a registration will
> >  expire.  The proxy needs to be able to retrieve the information from
> >  the registrar using some mechanism.  Such mechanisms are outside the
> >  scope of this document, but could be implemented e.g., using the
> >  SIPregistration event package mechanism [RFC3680].
> >
> >Nit: "SIP registration"
>
> Has been fixed.
>
> >This mechanism seems to be predicated on an architecture in which the 
> proxy must
> >be on the traffic path. Although it's problematic from a "what 
> proxies are
> >expected to do" perspective, it seems like the proxy could glean this
> >information from the 200 response to the REGISTER request. (I mean, 
> the proxy is
> >already reading parameters out of the contact header field, so the 
> behavior of
> >acting on registration information is already assumed). The proxy 
> would, of
> >course, need to run its own timers, but that seems to be a pretty minor
> >requirement, given everything else involved here.
>
> When I previously replied to your COMMENT, I said the following:
>
> "One way to implement the "retrieve the information from the 
> registrar" could of course be using own timers.
> But, I don't think we should specify such behavior.
>
> Also, in some cases the proxy might be co-located with the "home 
> proxy", or some other network node,
> where the interface with the registrar already exists."
>
> No changes were done based on the comment.
>
> ---------------------------------------------------------------------------
>
> §5.3.1:
>
> >This is a major comment, and one that has a sufficient impact on 
> interop that I
> >had a long debate with myself about whether it should be a DISCUSS. 
> Please take
> >it very seriously.
> >
> >  Otherwise, if the pn-provider SIP URI parameter identifies a type of
> >  PNS that the proxy does not support, or if the REGISTER request does
> >  not contain all additional information required for the specific type
> >  of PNS, the proxy MUST either forward the request (e.g., if the proxy
> >  knows that another proxy that will receive the REGISTER request
> >  supports the type of PNS)...
> >
> >How would the proxy know this?
>
> In the previous reply, I said "local configuration".
>
> It has been clarified in the text, and the text in section 5.6.1.1 now 
> says:
>
> "If the proxy knows (by means of local configuration)"
> >Features like suppressing PNS behavior when a "sip.pns" feature 
> capability is
> >present in the REGISTER imply that the various nodes in the network 
> discover
> >capabilities of their neighbors automatically (which is consistent 
> with the way
> >SIP does features), while this provision seems to require provisioned 
> knowledge.
> >This is going to be operationally very confusing.
> >
> >At the very least, the document needs to call out how this "knowledge" is
> >obtained. In the more general sense, since a client cannot rely on 
> the proxy
> >supporting *any* kind of PNS, the use of 555 in the way specified 
> here is at
> >best an optimization -- and, since the configured information can 
> conflict with
> >actual reality, it's an optimization that can actually break things 
> unless
> >extreme care is exercised. (e.g., if the proxy is configured to 
> "know" that the
> >next proxy cannot provide push service, but this knowledge is wrong, 
> then the
> >network is unnecessarily broken.)
> >
> >My rather strong recommendation is to remove this code, and let the 
> client rely
> >on the lack of indication of support in the response indicate that 
> the feature
> >is not supported.
>
> In my previous reply I said:
>
> "I would like to keep the code, because there are cases where one 
> wants the register to be rejected
> (rather than accepted, but without indication of supported PNS) if the 
> PNS is not supported.
>
> Also, there are already deployments of 555, so I'd prefer to keep it, 
> as it doesn't break anything."
>
> The 555 response code has been kept, and regarding the proxy knowing 
> it was clarified that it is based on local configuration (see above).
>
> ---------------------------------------------------------------------------
>
> §5.3.1:
>
> >  o  if the proxy received a 'sip.pnsreg' media feature tag in the
> >     REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature-
> >     capability indicator with an indicator value bigger than 120 in
> >     the response, unless the proxy always want to request push
> >
> >Nit: "...wants..."
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> §5.3.2:
>
> >  If the contact of the REGISTER request does not match
> >  the Request-URI of the SIP request to be forwarded, or if the contact
> >  was not present in the REGISTER response, the proxy MUST reject the
> >  SIP request with a 404 (Not Found) response.
> >
> >This seems to be a very strong requirement ("MUST") when, e.g., many 
> or most
> >networks may want to return a 480 instead of a 404. I think what you want to say
> >is something like "...MUST reject the SIP request. Response codes of 
> either
> >404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but 
> other
> >appropriate codes may be used as well."
>
> This has been addressed with the following text:
>
> "It is RECOMMENDED that the proxy sends either a 404 (Not
>  Found) response or a 480 (Temporarily Unavailable) response to the
>  SIP request, but other response codes can be used as well."
>
> ---------------------------------------------------------------------------
>
> §5.3.2:
>
> >  The reason the proxy needs to wait for the REGISTER response before
> >  forwarding the SIP request is to make sure that the REGISTER request
> >  has been accepted by the registrar, and that the UA which initiated
> >
> >Nit: "...the UA that initiated..."
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> §5.3.2:
>
> >  In case of non-2xx response to the REGISTER request, the proxy MUST
> >  reject the SIP request with a 404 (Not Found) response.
> >
> >  If the push notification request fails (see PNS-specific
> >  documentation for details), the proxy MUST reject the SIP request
> >  with a 480 (Temporarily Unavailable) response.
> >
> >  If the proxy does not receive the REGISTER request from the UA within
> >  a given time after the proxy has requested the push notification, the
> >  proxy MUST reject the request with a 480 (Temporarily Unavailable)
> >  response.  The time value is set based on local policy.
> >
> >As above, this seems way too restrictive in terms of mandating 
> specific error
> >codes. It may well be the case that a network would want to treat these
> >situations identically from the perspective of the calling party.
>
> Has been addressed (see above).
>
> ---------------------------------------------------------------------------
>
> §5.3.2:
>
> >  Otherwise the
> >  proxy MUST reject the SIP request with a 480 (Temporarily
> >  Unavailable) response.
> >
> >Same comment as above.
>
> Has been addressed (see above).
>
> ---------------------------------------------------------------------------
>
> §6.1.1:
>
> >  When the UA sends in initial request for a dialog, or a 2xx response
> >
> >Nit: "...sends an initial request..."
>
> Has been fixed.
>
> >  purr' SIP URI parameter in the Contact header of the request or
> >
> >Nit: "...Contact header field..."
>
> Has been fixed.
>
> >  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give
> >  dialog, the UA needs to include a 'pn-purr' parameter in the Contact
> >
> >Nit: "...given dialog..."
>
> Has been fixed.
>
> >  dialog, the UA needs to include a 'pn-purr' parameter in the Contact
> >  header of the request or response for each dialog in which the UA is
> >
> >Nit: "...Contact header field..."
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> §6.1.1:
>
> >  The UA MUST include a parameter value identical to the the
> >  last 'sip.pnspurr' feature-capability indicator that it received in a
> >  REGISTER response.
> >
> >This is incredibly confusing, as the "sip.pnspurr" indicator has not been
> >mentioned in the document so far. Please revise as something along 
> the lines of:
> >
> >  The UA MUST include a parameter value identical to the the last
> >  'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it
> >  received in a REGISTER response.
> >
> >Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR
> >concept is properly introduced before protocol procedures are defined 
> for it.
>
> This has been addressed, by adding a reference to Section 6.2.1.
>
> ---------------------------------------------------------------------------
> *
> §6.1.1:
>
> >  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give
> >  dialog, the UA needs to include a 'pn-purr' parameter in the Contact
> >  header of the request or response for each dialog in which the UA is
> >  willing to receive push notifications triggered by incoming mid-
> >  dialog requests.
> >
> >Similar to the above, this is a very confusing introduction of the 
> "pn-purr" URI
> >parameter.
>
> I realized this has been fixed in the wrong section. I will fix that 
> by adding a reference to Section 6.2.1.
>
> Note, though, that the first occurrence of 'pn-purr' SIP URI parameter 
> is in the first paragraph of section 6.1.1, so I will add the 
> reference there.
>
> ---------------------------------------------------------------------------
>
> §6.2.2:
>
> >  Contact header field with a PURR value that the proxy has generated
> >  Section 6.2.2, the proxy MUST add a Record-Route header to the
> >  request, to insert itself in the dialog route [RFC3261].
> >
> >This "Section 6.2.2" makes the sentence impossible to read. Is it 
> intended to be
> >in parentheses?
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> §6.2.3:
>
> >  As described in Section 5.3.2, while waiting for the push
> >  notification request to succeed, and the associated REGISTER request
> >  to arrive from the SIP UA, the proxy needs to take into consideration
> >  that the transaction associated with the NOTIFY request will
> >  eventually time out at the sender of the request (UAC), and the
> >  sender will consider the transaction a failure.
> >
> >I think this needs some discussion about the impact of the error 
> codes selected
> >by the proxy on the dialog and its usages. For example:
> >
> >* If the proxy sends a 404 to prevent a transaction timeout, it will 
> destroy the
> >  dialog and all of its usages
> >
> >* If the proxy sends a 480 to prevent a transaction timeout, it will 
> destroy the
> >  usage, but not other usages in the dialog (if any)
> >
> >* If the proxy sends a 504 to prevent a transaction timeout, it will 
> keep the
> >  dialog and the usage alive, and allow the client to re-try at a 
> later time.
> >  Simply allowing the transaction to time out will have the same 
> effect, albeit
> > with more message retransmissions.
> >
> > Pointing to RFC 5057 might be useful here.
>
> This has been addressed. The text in Section 6.2.3 now says:
>
>    "When a proxy sends an error response to a mid-dialog request 
> (e.g.,    due to a transaction time out), the proxy SHOULD select a 
> response    code that only impacts the transaction associated with the 
> request    ([RFC5079])."
>
> ---------------------------------------------------------------------------
>
> §8.7:
>
> >    Parameter value characters that are not part of pvalue needs to be
> >    escaped, as defined in RFC 3261.
> >
> >Nit: "...need to be escaped..."
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> §9:
>
> >  When a new value is registered to the PNS Sub-registry, a reference
> >  to a specification which describes the usage of the PNS associated
> >
> >Nit: "...specification that describes..."
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> §§10-12:
>
> >Nit: It seems like these should all be subsections of section 9.
>
> In my previous reply I said:
>
> "The idea was that the PNS registrations are in separate main 
> sections, as they could even be in a separate document."
>
> No changes were done based on this comment.
>
> ---------------------------------------------------------------------------
>
> §10:
>
> >  The Topic consists of the Bundle ID, which uniquelly identifies an
> >  appliciation, and a service value that identifies a service
> >
> >Nit: "uniquely"
> >Nit: "application"
>
> This has been fixed.
>
> ---------------------------------------------------------------------------
>
> §10:
>
> >  Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip
> >
> >Please use an RFC 2026 domain for this example; e.g.:
> >
> >  Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> §11:
>
> >  [RFC8292] defines a mechanism which allows a proxy to identity itself
> >
> > Nit: "...mechanism that allows..."
>
> Has been fixed.
>
> ---------------------------------------------------------------------------
>
> Regards,
>
> Christer
>