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

Stewart Bryant <stewart.bryant@gmail.com> Mon, 24 December 2018 10:01 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14D812008A; Mon, 24 Dec 2018 02:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yG1KDerFUz-K; Mon, 24 Dec 2018 02:01:49 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 42ED6130EE0; Mon, 24 Dec 2018 02:01:49 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id t6so11094975wrr.12; Mon, 24 Dec 2018 02:01:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=5iVbgOaexvYf5/n9Fmyx8ghBz2zXNvKCn9uPM8TVaYQ=; b=nO6FSrOCKB+XmA7rsxy9383kD/xVi49MfPFw4wPcJdL3KMQ5CmGKMSFivonbHrsr5v 6Q3zkjaZyt/Ufd2iwiPu7U8xuk+a/Rakxea3+aIQ3m5pG++EbNL7sC2/mAAAb1m6VKFB OWOW8iH34SgMTWguEM071XUrlqKY8GUqKfdGHZN18BzsYq8GZ0PlHi2dUj9+s9x929ka cd2aoFavUY6cOKWmbN2h6E4WurMhByjchgCNBEgTX94GyP5lEKGinHdQoXv4TEEjI8RU shCoF25g/U13IipT0wueO/o3vv8lD/TciZjppBNj3YuuYitbkhBaRiCmBF3gs6Px2WLV BENA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=5iVbgOaexvYf5/n9Fmyx8ghBz2zXNvKCn9uPM8TVaYQ=; b=QSt1oWahm/7AEL2xYBjIuw76aup1n+zYKjHxdvWHqxOGUfMeA9vWS/Camq31BOf71a o+VVkBo9qyrrJ3ekXWEP3b492eOaxuHBONFHvDT9uvBtnA57tYw3CY8St2bIUl743m2I EDH5+gOJmeLfRWLIJik+aYbDJ1M8wFJu9zgWooXuzhqXzJYYPqtIGmUsPTosVOQIF71/ Epd8fkMrQpZ/Ww4Xn6D4p1UbM9yTGSr1tBPMJs+66Y03JWrSjJ1j7UPwRG2zF+pXnBst NEeQDORwWJTO4ORjhWW0cBdiwWR32g97AxWBLh7qkThYW4BgOWm3zkvfrGHCSbiUMh9M 6qKw==
X-Gm-Message-State: AJcUukf5abo9+hl899LndrnOUAFpyHRIC1R7QwJENpp+cp0a05iIdHDd jTlnGL1BGlHteoZ0SpNq2pmfTUXNWf4=
X-Google-Smtp-Source: ALg8bN5SAlPdiRrGBpJedyMnotE1rW9aaNYZ2FXsq2FTmhswsUqpTCsTyajl4b+M03itXzXODpJF3Q==
X-Received: by 2002:a5d:448f:: with SMTP id j15mr10614607wrq.108.1545645707320; Mon, 24 Dec 2018 02:01:47 -0800 (PST)
Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id w6sm20500696wme.46.2018.12.24.02.01.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Dec 2018 02:01:46 -0800 (PST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "sipcore@ietf.org" <sipcore@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-sipcore-sip-push.all@ietf.org" <draft-ietf-sipcore-sip-push.all@ietf.org>
References: <044AE9AD-72F5-40D2-8A35-76E97D2F0A8D@ericsson.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <bac0b4de-f9b0-1da9-2666-4e1cdd8a4bea@gmail.com>
Date: Mon, 24 Dec 2018 10:01:45 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <044AE9AD-72F5-40D2-8A35-76E97D2F0A8D@ericsson.com>
Content-Type: multipart/alternative; boundary="------------5065D75275A7FFD3FB7E9225"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/30xcUD4UGX4TXIcMrS3qxs4q2Qk>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-sipcore-sip-push-21
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2018 10:01:52 -0000

On 20/12/2018 15:37, Christer Holmberg wrote:
>
> Hi Stewart,
>
> Thank You for the review! Please see inline.
>
> >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:alice@example.com SIP/2.0
>
> >    Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
>
> >    Max-Forwards: 70
>
> >    To: Alice <sip:alice@example.com>
>
> >    From: Alice <sip:alice@example.com>;tag=456248
>
> >    Call-ID: 843817637684230@998sdasdh09
>
> >    CSeq: 1826 REGISTER
>
> >    Contact: <sip:alice@alicemobile.example.com;
>
> >      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
>
> > SB> packet flow digram and the text that follows.
>
> I could add the following:
>
> “Below is an example of a SIP REGISTER request in Figure 1.”
>

SB> Thank you, that would clarify what was happening.

> =========
>
> >  Contact: IESG (iesg@ietf.org <mailto:iesg@ietf.org>)
>
> >
>
> > SB> Is the whole IESG the most appropriate first point of contact?
>
> That is what I was told :)
>
> Note that I have used it also for other documents.
>
SB> Whatever the IESG want... :)


> =========
>
> >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
>
> I will add a note to the RFC editor about that.
>
> “[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 
> document.]”
>
SB> That would be a fine way of clarifying it to the editors and those 
that read the pre-edited final text.

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

Best regards

Stewart


> =========
>
> Regards,
>
> Christer
>