Re: [mile] Artart last call review of draft-ietf-mile-rolie-10

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Martin,

Could you clarify which XML issues you mean? The rolie:format / rolie:property elements or something else?

rolie:format is necessary beyond media types for differentiating between formats that don't have their own media type, and for making clear the difference between a "media type" and a "format". Media types provide information about the serialization of content, but don't actually define the model of the content. Schemas can be used to help the parser understand the content, rolie:format provides a means to describe both the model and the schema of the content. We could solve this by providing some modified media type, but this would require just as much specification as our current solution. As an example, how would we best specify to a consumer that the content element links to an IODEF document? It's media type is XML, but there remains information that can only be gleaned  by downloading the entire content file.

rolie:property has a couple of advantages over defining the key-value pairs in XML. Defining new elements in XML is expensive. In the ROLIE core document we define 4 new properties, which would yield 4 new elements in the schema. In our Software Descriptor we define another software specific property, and we may add more as we iterate the draft. There are two other extensions in development that may add new properties as well. rolie:property provides a means to easily define new properties without generating a huge number of new elements. 

Would it be useful to clarify this further in the specification, or do you still have technical concerns?

Thanks,
Stephen

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Thursday, November 02, 2017 6:29 PM
> To: Banghart, Stephen A. (Fed) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> I just wanted to follow up on this.  I see that the draft has been revised a few
> times, but I haven't seen any response to my comments about the XML, or
> any changes related to them.
> 
> I ask, because IANA is asking about the XML registrations.  If the working
> group consensus is that I'm in the rough, let me know and I'll tell IANA that
> the schema is good to go.
> 
> On Fri, Oct 20, 2017 at 10:53 AM, Martin Thomson
> <[e-mail]> wrote:
> > Thanks Stephen,
> >
> > Most of this looks good (I'll trust that your representation of the
> > changes is accurate rather than wade through XML, though I have
> > reviewed some of the changes).
> >
> > On Fri, Oct 20, 2017 at 3:24 AM, Banghart, Stephen A. (Fed)
> > <[e-mail]> wrote:
> >>> The requirements in Section 5.3 on TLS use are unnecessarily strict.
> >>> It's great to recommend the use of TLS 1.2, but given that the
> >>> document has no real requirement on any particular version of TLS,
> >>> the use of "MUST" here is not needed.  Similarly, the prohibition on
> >>> the use of 0-RTT is groundless.  The lengthy list of requirements
> >>> around certificate validation only risk creating a conflict with
> >>> advice in other RFCs.  Many, if not all, of these requirements are
> >>> transitively included by way of referencing HTTPS documents.  I would
> prefer to see this entire section reduced to a simple RFC 7525 reference.
> >>
> >> The majority of the section has been reduced to a RFC 7525 reference.
> We believe that the benefits provided by 0-RTT don't outweigh the loss of
> forward secrecy. The text currently places this as a suggestion from the
> authors, and not a normative requirement.
> >
> > I'm going to push on this one more time.  0-RTT does not necessarily
> > compromise forward secrecy.  It is also entirely possible to deploy
> > 0-RTT without risk of replay attack.  But these facts don't seem
> > persuasive because it is possible to implement the feature with these
> > risks.
> >
> > The text you provide indicates that it is replay you are concerned
> > about.  Do you have any analysis that indicates that someone deploying
> > a server that enables early data would produce harm?  Does that
> > analysis suggest any other alternative mitigation strategies?
> >
> > Again, I would prefer that the draft remain silent on this subject.  I
> > realize that I'm in the rough here, but I consider this to be a test
> > case for this.  The next person who uses HTTP will see your text,
> > notice that it is good, and copy it.  It becomes precedent to forbid
> > the use of 0-RTT and we forget *why*.  I would prefer that this text
> > be better motivated if it is included.
> >
> >>> User authentication is under-specified.
> >
> > The new text is much more concise and targeted, thank you.
> >
> >>> In Section 6.2.3, what is the advantage of "rolie:format" over
> >>> having a well- defined media type?  Media types can take advantage
> >>> of content negotiation, existing support in link relations, and other
> existing tools.
> >>> This rolie:format element has namespace, format, and schema; these
> >>> are not useful to anyone that is ignorant of their contents.  The
> >>> only advantage I see is that syntax might be validated, but
> >>> semantics can't be extracted.  There's a lot of implied work in
> >>> adding this element, but that doesn't seem to be justified by that
> >>> advantage.  (I see that RFC 7970 doesn't define a media type, but it
> >>> seems like it would be easier to correct that than to define an
> >>> element like this.)
> >>
> >> Atom:content has an attribute for media type, which provides
> information about the serialization of the content representation. In many
> cases, we found that different formats can appear for the same content
> within the same media type. For example, the same piece of information
> may be represented using two different XML Schemas. The rolie:format
> element allows the entry to clarify which "format" its using beyond which
> serialization it is using. Ultimately the format element is not registered
> anywhere, nor is its contents particularly standardized. We're providing the
> element as a tool for repository producers to use.
> >
> > This is, at least in my opinion, a mistake.  It creates another layer
> > of content negotiation that is not visible to HTTP.  If the same
> > information can be presented in two different formats, why is it not
> > possible to have two media types?  Or at least a parameterized media
> > type that identifies the format.
> >
> > The problem with defining elements is that they are costly.  Not so
> > much to specify, but to implement correctly.  If you are able to rely
> > on existing mechanisms, you should do that as much as possible.
> >
> > It doesn't sound like you have a concrete use case for this, which
> > makes me nervous.
> >
> >>> Section 6.2.4 defines a generic key-value mechanism.  But that is
> >>> something that XML is actually good at.  Why can't users that
> >>> require additional metadata use additional metadata as originally
> >>> defined by Atom?  That is, replace <rolie:property
> name="urn:ietf:params:rolie:property:csirt-iodef-id"
> >>> value="12345"/> with something like
> >>> <rolie:csirt-iodef-id>12345</rolie:csirt-iodef-id>.  The final
> >>> paragraph of the section recognizes this possibility.
> >>
> >> The latter example you provide is still possible, as unrecognized elements
> in ROLIE/Atom don't cause validation to fail, but are just potentially ignored
> by the client/server. The rolie:property element allows automated systems
> to have a globally available "vocabulary" of potentially available properties,
> that can be used to populate tables or fields in automated systems.
> >
> > I realize that the set of attributes you have might be useful in this
> > context.  But defining them in XML would be much easier.  You don't
> > create a new mechanism for expressing key-value pairs, and the
> > registry that goes with it.  That seems like a minor cost, but like in
> > the previous case, the choice to define another bespoke mechanism
> > comes with hidden costs.  Why bother when you have a perfectly
> > workable mechanism available to you already?
> >
> >>> Question: it's fairly widely accepted that use of IRIs in Atom has
> >>> been less than successful.  Do you want to mandate use of URIs
> >>> instead?  This would apply to both link relations and the "src" attribute.
> >>
> >> We wanted to stay in line with the requirements in Atom, if this becomes
> an issue it may be worth re-examining.
> >
> > This is your chance.  You don't get to go back or re-examine once your
> > protocol is widely deployed.