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

["jmh.direct" <[e-mail]>]

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 <[e-mail]> Date: 1/27/17  14:17  (GMT-06:00) To: [e-mail] Cc: Joel Halpern <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail] Subject: Re: Review of draft-mohali-dispatch-cause-for-service-number-12 
On 27 Jan 2017, at 11:15, [e-mail] 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:[e-mail]]
>> Envoyé : vendredi 16 décembre 2016 04:57
>> À : [e-mail]
>> Cc : [e-mail]; draft-mohali-dispatch-cause-for-service-
>> [e-mail]; [e-mail]
>> 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.