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 <[email protected]> Date: 1/27/17 14:17 (GMT-06:00) To: [email protected] Cc: Joel Halpern <[email protected]>, [email protected], [email protected], [email protected], [email protected] Subject: Re: Review of draft-mohali-dispatch-cause-for-service-number-12 On 27 Jan 2017, at 11:15, [email protected] 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:[email protected]] >> Envoyé : vendredi 16 décembre 2016 04:57 >> À : [email protected] >> Cc : [email protected]; draft-mohali-dispatch-cause-for-service- >> [email protected]; [email protected] >> 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.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
