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@xxxxxxxxxxx>
Date: 1/27/17 14:17 (GMT-06:00)
To: marianne.mohali@xxxxxxxxxx
Cc: Joel Halpern <jmh@xxxxxxxxxxxxxxx>, gen-art@xxxxxxxx, ietf@xxxxxxxx, draft-mohali-dispatch-cause-for-service-number.all@xxxxxxxx, dispatch@xxxxxxxx
Subject: Re: Review of draft-mohali-dispatch-cause-for-service-number-12
> 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@xxxxxxxxxxxxxxx]
>> Envoyé : vendredi 16 décembre 2016 04:57
>> À : gen-art@xxxxxxxx
>> Cc : ietf@xxxxxxxx; draft-mohali-dispatch-cause-for-service-
>> number.all@xxxxxxxx; dispatch@xxxxxxxx
>> 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.