Subject: Re: [Gen-art] Genart last call review of draft-ietf-sipcore-sip-push-21

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Jan 2019 09:03:46 +0000

Hi,

…

>>   Example: pn-prid = 00fc13adff78512
>>
>>   For more information about the APNs Topic and device token:
>>
>> SB> Is the following part of the example? If so it could usefully be delimited
>> SB> as such, otherwise, I don't understand why it is not a normal document
>> SB> reference.
>>
>>   https://developer.apple.com/library/archive/documentation/NetworkingI
>>   nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html
>>
>> SB> Similarly in the following section
>>
>> The link reference is not part of the example. Perhaps I could place to reference before the examples, to make that more clear?
>>
>> Are you suggesting that I add the link to the reference section, similar to document references?

> SB> Yes, if it is just a reference, I would have expected it to be treated just like any other reference, i.e. a pointer to a reference at
> the end of the document. That method also clarifies the matter of whether the reference is normative or informational which does not happen with embedded references.

You don’t need the reference in order to understand the draft. You need the reference if you are going to implement support for a specific PNS.

But, I have no problem to add the links to the reference section. Are you aware of any examples of referencing web links?

Regards,

Christer

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 9 Jan 2019 10:26:53 -0500

Stewart, thanks for your review. Christer, thanks for addressing Stewart’s comments. I entered a No Objection ballot.

Alissa

> On Dec 19, 2018, at 10:49 AM, Stewart Bryant <[email-masked]> wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-sipcore-sip-push-21
> Reviewer: Stewart Bryant
> Review Date: 2018-12-19
> IETF LC End Date: 2018-12-21
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: A well written document with some minor points that could use a little
> attention.
> 
> Major issues: None
> 
> Minor issues:
> 
> In Figure 1 the following is included:
> 
>     REGISTER sip:[email-masked] SIP/2.0
>     Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
>     Max-Forwards: 70
>     To: Alice <sip:[email-masked]>
>     From: Alice <sip:[email-masked]>;tag=456248
>     Call-ID: 843817637684230@998sdasdh09
>     CSeq: 1826 REGISTER
>     Contact: <sip:[email-masked];
>       pn-provider=acme;
>       pn-param=acme-param;
>       pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
>     Expires: 7200
>     Content-Length: 0
> 
> SB> However I don't at this stage of the text see the relationship between the
> packet flow digram and the text that follows.
> 
> =========
>   Contact: IESG ([email-masked])
> 
> SB> Is the whole IESG the most appropriate first point of contact?
> 
> =========
> 
> Nits/editorial comments:
> Presumably the references to RFC XXXX will be replaced by RFC <this RFC> but
> that does not seem to be noted in the text
> 
> ========
> 
>   As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
> SB> Typo s/dicussed/discussed/
> 
> ========
> 
> as SB>  such, otherwise, I don't understand why it is not a normal document
> SB> reference.
> 
> =========
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art