Re: [sacm] Adam Roach's No Objection on draft-ietf-sacm-nea-swima-patnc-02: (with COMMENT)

[Kathleen Moriarty <[e-mail]>]

Thank you, all!

Sent from my mobile device

> On Feb 27, 2018, at 7:19 PM, Adam Roach <[e-mail]> wrote:
> 
> Yes, the latest version addresses my concerns. Thanks to the authors for a rapid turn-around on these edits!
> 
> /a
> 
>> On 2/27/18 3:55 PM, Kathleen Moriarty wrote:
>> Adam,
>> 
>> Please confirm if you agree your comments have been addressed.
>> 
>> Thank you!
>> Kathleen
>> 
>> On Tue, Feb 27, 2018 at 4:51 PM, Schmidt, Charles M.
>> <[e-mail]> wrote:
>>> Hello,
>>> 
>>> Thanks a bunch for the feedback. I agree with your comments and believe they are addressed in the new (-03) draft.
>>> 
>>> Thank you,
>>> Charles
>>> 
>>>> -----Original Message-----
>>>> From: Adam Roach [mailto:[e-mail]]
>>>> Sent: Thursday, February 22, 2018 1:41 AM
>>>> To: The IESG <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; Karen
>>>> O'Donoghue <[e-mail]>; [e-mail];
>>>> [e-mail]; [e-mail]
>>>> Subject: Adam Roach's No Objection on draft-ietf-sacm-nea-swima-patnc-02:
>>>> (with COMMENT)
>>>> 
>>>> Adam Roach has entered the following ballot position for
>>>> draft-ietf-sacm-nea-swima-patnc-02: No Objection
>>>> 
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Thanks for everyone's work on this document. I support Ben's DISCUSS, his
>>>> concerns regarding the treatment of privacy in §8, and EKR's concerns
>>>> regarding the phrasing "not generally considered to be sensitive."
>>>> 
>>>> I also have a few very important comments about this document's
>>>> handling of URIs.
>>>> 
>>>> §3.4.4:
>>>>>  The location is expressed as a URI string consisting of a scheme and
>>>>>  path.  [RFC3986] The location URI does not include an authority part.
>>>>>  The URI schema describes the context of the described location.  For
>>>>>  example, in most cases the location of the installed software product
>>>>>  will be expressed in terms of its path in the filesystem.  For such
>>>>>  locations, the location URI scheme MUST be "file" or the URI MUST
>>>>>  appear without a scheme.  (I.e., "file" is default scheme.)  It is
>>>>>  possible that other schemes could be used to represent other location
>>>>>  contexts.  Apart from reserving the "file" scheme, this specification
>>>>>  does not reserve schemes.  When representing software products in
>>>>>  other location contexts, tools MUST be consistent in their use of
>>>>>  schemes, but the exact string used in those schemes is not
>>>>>  normatively defined here.
>>>> Please cite RFC 8098 in this paragraph.
>>>> 
>>>> Saying that a URI can appear without a scheme is at least confusing and
>>>> probably
>>>> ambiguous. For example, I can't tell which of the following syntaxes are
>>>> expected and/or allowed:
>>>> 
>>>> 1. :///Applications/TurnipTwaddler
>>>> 2. ///Applications/TurnipTwaddler
>>>> 3. /Applications/TurnipTwaddler
>>>> 
>>>> Read literally, the quoted paragraph describes the first. It probably means to
>>>> describe the second (maybe?), but I suspect some implementors will
>>>> interpret
>>>> it as the third.
>>>> 
>>>> This becomes even more problematic for Windows, where it might be
>>>> interpreted
>>>> to mean any of *four* things (where the final one is clearly wrong due to
>>>> potential confusion between drive letters and URI schemes -- but which I'm
>>>> sure will be implemented if not clearly spelled out):
>>>> 
>>>> 1. :///C:/Program%20Files/TurnipTwaddler
>>>> 2. ///C:/Program%20Files/TurnipTwaddler
>>>> 3. /C:/Program%20Files/TurnipTwaddler
>>>> 4. C:/Program%20Files/TurnipTwaddler
>>>> 
>>>> To be clear, whatever you define in this document cannot allow the omission
>>>> of a
>>>> scheme to result in Form #4 above, as this is syntactically ambiguous.
>>>> 
>>>> It also probably bears reiterating that omitting the "file" scheme from a URI
>>>> doesn't exempt it from encoding according to RFC 8089 section 4 (e.g.,
>>>> including an unescaped space, as in "Program Files", would be syntactically
>>>> invalid).
>>>> 
>>>> Finally, I question the assertion that "The location URI does not include an
>>>> authority part." It's been a while since I used Windows on a regular basis, but
>>>> my recollection is that files -- including applications -- can be accessed from
>>>> a CIFS filesystem without associating a local mount point with them. It would
>>>> be
>>>> impossible to describe the location of such applications if the authority is
>>>> required to be omitted. It is easy to anticipate that future iterations of,
>>>> e.g., Linux may have similar properties. (Popular desktops already allow
>>>> userland access of files on unmounted access using full URIs, which
>>>> necessarily
>>>> include authority components; it is not far-fetched to imagine that this
>>>> functionality might be incorporated into the kernel at some point).
>>>> 
>>>> ---------------------------------------------------------------------------
>>>> 
>>>> The following appears in several places:
>>>> 
>>>>>  | Software       | A string containing the Software Locator value.  |
>>>>>  | Locator        | This is expressed as a URI. This field value     |
>>>>>  |                | MUST be normalized to Network Unicode format as  |
>>>>>  |                | described in Section 3.4.4. This string MUST NOT |
>>>>>  |                | be NULL terminated.                              |
>>>> Section 3.4.4 doesn't describe the use of Network Unicode format, so this
>>>> text
>>>> is confusing. I'll note that file URIs are generally going to be percent
>>>> encoded, so they shouldn't contain any non-ASCII characters. Section 4 of
>>>> RFC
>>>> 8089 deals with encoding considerations for file URIs. Other URIs have their
>>>> own
>>>> encoding considerations, and it would be somewhat ambitious for this
>>>> document to
>>>> take on any encoding specification above and beyond what is already
>>>> defined for
>>>> each scheme.
>>>> 
>>>> 
>> 
>> 
>