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

[Ben Campbell]

This looks good to me. Please submit a new revision when you are ready.

Since these changes look minor and not likely to be controversial, I am going 
to go ahead and create a ballot for this. It will likely end up on the 10 
January telechat.

Thanks!

Ben.

> On Dec 21, 2018, at 2:50 AM, Christer Holmberg 
>  wrote:
> 
> Hi,
> 
> Based on the gen-art comments from Stewart, I have created a pull request for 
> the suggested changes.
> 
> https://github.com/cdh4u/draft-sip-push/pull/31 
> 
> 
> Regards,
> 
> Christer
> 
> From: Christer Holmberg  >
> Date: Thursday, 20 December 2018 at 17.37
> To: Stewart Bryant  >, "gen-art@ietf.org 
> " mailto:gen-art@ietf.org>>
> Cc: "sipc...@ietf.org "  >, "i...@ietf.org " 
> mailto:i...@ietf.org>>, 
> "draft-ietf-sipcore-sip-push@ietf.org 
> " 
>  >
> Subject: Re: [Gen-art] Genart last call review of 
> draft-ietf-sipcore-sip-push-21
> Resent-From: mailto:alias-boun...@ietf.org>>
> Resent-To: Christer Holmberg  >,  >, "A. Mahoney"  >, Brian Rosen  >, Ben Campbell  >, "a...@nostrum.com " 
> mailto:a...@nostrum.com>>,  >, Brian Rosen  >
> Resent-Date: Thursday, 20 December 2018 at 17.37
> 
> 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:al...@example.com  SIP/2.0
> > Via: SIP/2.0/TCP alicemobile.example.com:5060 
> > ;branch=z9hG4bKnashds7
> > Max-Forwards: 70
> > To: Alice >
> > From: Alice >;tag=456248
> > Call-ID: 843817637684230@998sdasdh09
> > CSeq: 1826 REGISTER
> > Contact:  > ;
> >   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.”
> 
> =
> 
> >   Contact: IESG (i...@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.
> 
> =
> 
> >Nits/editorial comments:
> >Presumably the references to RFC  will be replaced by 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 RFC with the RFC number of this 
> document.]”
> 
> 
> 
> > SB> As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
> > SB> Typo s/dicussed/discussed/
> 
> I will fix as suggested.
> 
> 
> 
> >   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?
> 
> =
> 
> Regards,
> 
> Christer



signature.asc
Description: Message signed with OpenPGP
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Ben Campbell]

> On Dec 20, 2018, at 9:37 AM, Christer Holmberg 
>  wrote:
> 
> >   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?
> 

One common approachto this  is to add a URL reference section after the normal 
references.

Thanks!

Ben.


signature.asc
Description: Message signed with OpenPGP
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Thanks all.

Dino

> On Dec 20, 2018, at 10:57 PM,  
>  wrote:
> 
> Re-,
> 
> Seems we are all in agreement. 
> 
> I implemented the changes to 8113bis in my local copy. 
> 
> Thank you, Brian. 
> 
> Cheers,
> Med 
> 
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : vendredi 21 décembre 2018 00:29
>> À : Brian E Carpenter
>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-art@ietf.org;
>> l...@ietf.org; draft-ietf-lisp-rfc8113bis@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>>> On 2018-12-21 09:18, Dino Farinacci wrote:
 Brian wants to drop the reference to 6833bis from 8113bis. I am fine with
>> that. That reference being at the top of the draft saying “Updates 6833bis”.
>> If we remove that, he may concur. Please confirm Brian (again).
>>> 
>>> Yes, that would resolve my concern.
>> 
>> Thanks.
>> 
 Like I have mentioned to you before, the IETF “Updates” lingo is confusing
>> and really not useful unless a draft replaces a previous draft. And this is
>> not the case here.
>>> 
>>> That's a debate for the RFC-interest list perhaps. IMHO the issue is that
>> "Updates" sometimes means "Extends" and sometimes means "Modifies".
>> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to
>> create confusion.
>> 
>> Then maybe those words should be used.
>> 
>> Dino
>> 
>>> 
>>> Thanks
>>>  Brian
>>> 
 
 Dino
 
> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern 
>> wrote:
> 
> Dino, Med, please confirm if I am reading the thread properly:
> 
> I believe that the proposal is to make the small change below to 6833bis
>> and to drop the "updates" reference from 8113bis to 6833bis.
> 
> I believe Dino's question was whether Brian agreed that the combination
>> suggested would address his concern.
> 
> Yours,
> Joel
> 
> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>> I may be missing something but I don't see how 8113bis can
>> logically cite 8113, which it replaces.
>> Frankly I think you've collectively created a plate of citation
>> spaghetti by not moving the IANA considerations for the type field
>> registry into 6830bis, which is where they naturally belong. If you
>> don't want to do that, I think you have to leave them in 8113bis and
>> simply lose the citation of 6833bis, which serves no purpose that
>> I can see.
>> Regards
>>  Brian
>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>> 
>>> Dino
>>> ngo
 On Dec 19, 2018, at 11:35 PM, 
>>  wrote:
 
 Hi Dino,
 
 OLD:
 
 Values in the "Not Assigned" range can be assigned according to
 procedures in [RFC8126].
 
 NEW:
 
 Values in the "Not Assigned" range can be assigned via Standards
 Action [RFC8113].
 
 Cheers,
 Med
 
> -Message d'origine-
> De : Dino Farinacci [mailto:farina...@gmail.com]
> Envoyé : mercredi 19 décembre 2018 19:00
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org;
>> l...@ietf.org;
> draft-ietf-lisp-rfc8113bis@ietf.org
> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-
>> rfc8113bis-01
> 
> What does fixing in (1) mean?
> 
> Dino
> 
>> On Dec 19, 2018, at 3:51 AM, 
>  wrote:
>> 
>> Hi all,
>> 
>> Brian, whether to maintain the document standalone was discussed by
>> the WG.
> You may refer, for example, to the message from Deborah which
>> clarifies this
> point: https://www.ietf.org/mail-
>> archive/web/lisp/current/msg07886.html. One
> of the outcomes of that discussion is to add an "updates" header to
>> 8113bis.
>> 
>> FWIW, one of the issues that led to that conclusion was whether to
>> cite
> rfc8113bis as normative in 6833bis (the approach I initially
>> supported) and
> agreed by Dino (https://www.ietf.org/mail-
> archive/web/lisp/current/msg07882.html). Deborah convinced me that
>> citing
> 8113bis will lead to circular dependency. Which is a fair argument.
>> 
>> The "updates" tag was justified as follows:
>> 
>> (1)
>> 
>> RFC6833bis includes the following:
>> 
>> Values in the "Not Assigned" range can be assigned according to
>> procedures in [RFC8126].
>> 
>> That text is updated by RFC8113bis to be aligned with 8113:
>> 
>> Values can be assigned via Standards Action
>> 
>> (2)
>> 
>> RFC8113bis extends the type field to grab more bits/values when the
> available 

Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08

[Dan Romascanu]

Hi Stephane,

Draft 09 addresses my (minor) concerns. Thank you for the prompt response
end for the edits.

Regards,

Dan


On Fri, Dec 21, 2018 at 3:46 PM  wrote:

> Hi,
>
> The -09 has been published and should address your comment.
>
> Feel free to raise any additional concern.
>
> Brgds,
>
> -Original Message-
> From: Dan Romascanu [mailto:droma...@gmail.com]
> Sent: Tuesday, December 11, 2018 15:29
> To: gen-art@ietf.org
> Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; i...@ietf.org;
> rt...@ietf.org; droma...@gmail.com
> Subject: Genart last call review of
> draft-ietf-rtgwg-spf-uloop-pb-statement-08
>
> Reviewer: Dan Romascanu
> 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
>
> .
>
> Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08
> Reviewer: Dan Romascanu
> Review Date: 2018-12-11
> IETF LC End Date: 2018-12-18
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> Ready
>
> This document analyzes the impact of using non-standardized IGP Link State
> implementations resulting in non-consistent tuning of parameters in the
> network
> and increased possibility of creating micro-loops. It can be viewed as a
> problem statement for standardized solutions like RFC 8405.
>
> The document is short and clear for implementers and operators familiar
> with
> networks running this class of protocols. Diagrams and table help in
> reading
> and understanding the material.
>
> Major issues:
>
> none
>
> Minor issues:
>
> none
>
> Nits/editorial comments:
>
> 1. In the introduction:
>
> > For non standardized timers, implementations are free to implement it
>in any way.
>
> It is not obvious what 'it' means. I guess it's about different values of
> timers resulting in the possibility of micro-loops creation, but it would
> be
> better to clarify.
>
> 2. It would be useful to provide short explanations that make the figures
> more
> clear. In fig. 1 - what do the nodes represent (routers implementing the
> protocols), in fig. 2, and 3 - the abbreviations on the y axis
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08

[stephane.litkowski]

Hi,

The -09 has been published and should address your comment.

Feel free to raise any additional concern.

Brgds,

-Original Message-
From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Tuesday, December 11, 2018 15:29
To: gen-art@ietf.org
Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; i...@ietf.org; 
rt...@ietf.org; droma...@gmail.com
Subject: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08

Reviewer: Dan Romascanu
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

.

Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08
Reviewer: Dan Romascanu
Review Date: 2018-12-11
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary:

Ready

This document analyzes the impact of using non-standardized IGP Link State
implementations resulting in non-consistent tuning of parameters in the network
and increased possibility of creating micro-loops. It can be viewed as a
problem statement for standardized solutions like RFC 8405.

The document is short and clear for implementers and operators familiar with
networks running this class of protocols. Diagrams and table help in reading
and understanding the material.

Major issues:

none

Minor issues:

none

Nits/editorial comments:

1. In the introduction:

> For non standardized timers, implementations are free to implement it
   in any way.

It is not obvious what 'it' means. I guess it's about different values of
timers resulting in the possibility of micro-loops creation, but it would be
better to clarify.

2. It would be useful to provide short explanations that make the figures more
clear. In fig. 1 - what do the nodes represent (routers implementing the
protocols), in fig. 2, and 3 - the abbreviations on the y axis



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Christer Holmberg]

Hi,

Based on the gen-art comments from Stewart, I have created a pull request for 
the suggested changes.

https://github.com/cdh4u/draft-sip-push/pull/31

Regards,

Christer

From: Christer Holmberg 
Date: Thursday, 20 December 2018 at 17.37
To: Stewart Bryant , "gen-art@ietf.org" 

Cc: "sipc...@ietf.org" , "i...@ietf.org" , 
"draft-ietf-sipcore-sip-push@ietf.org" 

Subject: Re: [Gen-art] Genart last call review of draft-ietf-sipcore-sip-push-21
Resent-From: 
Resent-To: Christer Holmberg , 
, "A. Mahoney" , Brian 
Rosen , Ben Campbell , 
"a...@nostrum.com" , , Brian Rosen 

Resent-Date: Thursday, 20 December 2018 at 17.37

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:al...@example.com SIP/2.0
> Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
> Max-Forwards: 70
> To: Alice 
> From: Alice ;tag=456248
> Call-ID: 843817637684230@998sdasdh09
> CSeq: 1826 REGISTER
> Contact: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.”

=

>   Contact: IESG (i...@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.

=

>Nits/editorial comments:
>Presumably the references to RFC  will be replaced by 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 RFC with the RFC number of this 
document.]”



> SB> As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
> SB> Typo s/dicussed/discussed/

I will fix as suggested.



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

=

Regards,

Christer

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art