ietf
[Top] [All Lists]

Re: Review of draft-mohali-dispatch-cause-for-service-number-12

2017-01-27 17:01:29
Thank you.That seems a reasonable compromise among the constraints. 
Ypyrs,Joel


Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: Ben Campbell 
<ben(_at_)nostrum(_dot_)com> Date: 1/27/17  14:17  (GMT-06:00) To: 
marianne(_dot_)mohali(_at_)orange(_dot_)com Cc: Joel Halpern 
<jmh(_at_)joelhalpern(_dot_)com>, gen-art(_at_)ietf(_dot_)org, 
ietf(_at_)ietf(_dot_)org, 
draft-mohali-dispatch-cause-for-service-number(_dot_)all(_at_)ietf(_dot_)org, 
dispatch(_at_)ietf(_dot_)org Subject: Re: Review of 
draft-mohali-dispatch-cause-for-service-number-12 
On 27 Jan 2017, at 11:15, marianne(_dot_)mohali(_at_)orange(_dot_)com wrote:

Hi Joel,

I have submitted a new version (v-13) of the draft.
I have addressed your comment for IPv6 addresses format in the 
example.
Concerning your major comment, the discussion is leaded by Ben.

To that point: Please note that version 13 adds a comment to the end of 
the introduction to make it clear that this draft documents something 
that another group (3GPP) does. It is not an IETF standard.

Thanks!

Ben.


I hope I have correctly address your comment.
https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-service-number/

Best regards,
Marianne

-----Message d'origine-----
De : Joel Halpern [mailto:jmh(_at_)joelhalpern(_dot_)com]
Envoyé : vendredi 16 décembre 2016 04:57
À : gen-art(_at_)ietf(_dot_)org
Cc : ietf(_at_)ietf(_dot_)org; draft-mohali-dispatch-cause-for-service-
number(_dot_)all(_at_)ietf(_dot_)org; dispatch(_at_)ietf(_dot_)org
Objet : Review of draft-mohali-dispatch-cause-for-service-number-12

Reviewer: Joel Halpern
Review result: Ready with Issues

Major:
     This document defines a new code for use in SIP, and specifies 
new behavior
both for the code itself and for its use in history-info.  I am thus 
confused as to
how this can be an informational RFC.  It looks like it either 
Proposed Standard
or experimental.  Yes, I see that RFC 4458, which this updates is 
Informational.
But just because we did it wrong before does not make that behavior 
correct
now.  In addition to my understanding of the roles of different RFCs, 
I note that
RFC 3969 and the IANA registry both state that this assignment must 
be made
by a standards track RFC.

Minor:
    Given our emphasis on IPv6 over IPv4, would it not make sense for 
the
examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)


_________________________________________________________________________________________________________________________

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.
<Prev in Thread] Current Thread [Next in Thread>