Fwd: Re: Editorial revisions to FPC draft
Charlie Perkins <[email protected]> Thu, 16 Nov 2017 16:42:16 -0800
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============5508295618245925422== Content-Type: multipart/alternative; boundary="------------53ED2EFD46E539777132A77D" Content-Language: en-US This is a multi-part message in MIME format. --------------53ED2EFD46E539777132A77D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello folks, Here are some comments that I had sent to the co-authors. It was suggested that these discussions should really be carried out in a larger context. Any comments will be appreciated. I am in the process of receiving the editorial pen for the document and part of my purpose will be to reformulate some of the definitions. Regards, Charlie P. -------- Forwarded Message -------- Subject: Re: Editorial revisions to FPC draft Date: Tue, 14 Nov 2017 17:03:47 -0800 From: Charlie Perkins <[email protected]> To: Marco Liebsch <[email protected]>, Satoru Matsushima <[email protected]>, Sri Gundavelli (sgundave) <[email protected]>, Moses, Danny <[email protected]>, Bertz, Lyle T [CTO] <[email protected]> Hello again folks, Regarding some of the definitions... I'd like to suggest the following: - "xxxx-ID" should be *defined* to be an identifier. Not a reference. - "xxxx-Reference" should be *defined* to be a reference. I understand a reference to mean a way of locating an instance. An identifier could be a reference, if the identifier is also an index into an array of instances, or a key into a database (or a pointer in C [just kidding...]). - for the purposes of this draft, we could restrict "name" to mean a string of ASCII characters associated to an identifier. Not associated to a reference. If the string IS the identifier, then I am not sure if the identifier has to have a "name" attribute. - this, unfortunately, conflicts with the use of the word "namespace", which undoubtedly does NOT mean a space of strings of ASCII characters. Maybe "namespace" should be renamed to be "id-space". As a bit of background for these remarks, I would like to suggest that the document is quite abstract, by intention and design. And I think that is quite appropriate. But, abstraction has its costs. For one thing, the abstract concepts have to be defined *extremely carefully*. Otherwise the abstraction is more difficult to grasp. Another cost is that the abstraction has to be well motivated. This can be done by offering many examples. Or, you might say, many opportunities to connect the dots between the stratosphere and what's visible on the ground. ... Regards, Charlie P. ... --------------53ED2EFD46E539777132A77D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>Hello folks,</p> <p>Here are some comments that I had sent to the co-authors. It was suggested that these discussions should really be carried out in a larger context. Any comments will be appreciated. I am in the process of receiving the editorial pen for the document and part of my purpose will be to reformulate some of the definitions.</p> <p>Regards,<br> Charlie P.<br> </p> <div class="moz-forward-container"><br> <br> -------- Forwarded Message -------- <table class="moz-email-headers-table" cellspacing="0" cellpadding="0" border="0"> <tbody> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th> <td>Re: Editorial revisions to FPC draft</td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th> <td>Tue, 14 Nov 2017 17:03:47 -0800</td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th> <td>Charlie Perkins <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a></td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th> <td>Marco Liebsch <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>, Satoru Matsushima <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>, Sri Gundavelli (sgundave) <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>, Moses, Danny <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>, Bertz, Lyle T [CTO] <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a></td> </tr> </tbody> </table> <br> <br> <pre>Hello again folks, Regarding some of the definitions... I'd like to suggest the following: - "xxxx-ID" should be *defined* to be an identifier. Not a reference. - "xxxx-Reference" should be *defined* to be a reference. I understand a reference to mean a way of locating an instance. An identifier could be a reference, if the identifier is also an index into an array of instances, or a key into a database (or a pointer in C [just kidding...]). - for the purposes of this draft, we could restrict "name" to mean a string of ASCII characters associated to an identifier. Not associated to a reference. If the string IS the identifier, then I am not sure if the identifier has to have a "name" attribute. - this, unfortunately, conflicts with the use of the word "namespace", which undoubtedly does NOT mean a space of strings of ASCII characters. Maybe "namespace" should be renamed to be "id-space". As a bit of background for these remarks, I would like to suggest that the document is quite abstract, by intention and design. And I think that is quite appropriate. But, abstraction has its costs. For one thing, the abstract concepts have to be defined *extremely carefully*. Otherwise the abstraction is more difficult to grasp. Another cost is that the abstraction has to be well motivated. This can be done by offering many examples. Or, you might say, many opportunities to connect the dots between the stratosphere and what's visible on the ground. ... Regards, Charlie P. ... </pre> </div> </body> </html> --------------53ED2EFD46E539777132A77D-- --===============5508295618245925422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm --===============5508295618245925422==--