Subject: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Oct 2017 04:36:39 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-mile-rolie-12: Discuss

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-mile-rolie/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a useful document and I will be balloting "Yes" once the following
small issues are resolved/discussed (some of these come from Martin's ARTART
review):

1) 7.4.  The "rolie:property" Extension Point

   urn:ietf:params:rolie:property:content-id  The "value" attribute of
      this property is a text representation of an identifier pertaining
      to or extracted from the content referenced by the "src" attribute
      of the entry's atom:content element.

Maybe it is just me, but I can't figure out what is the syntax of this field.
Can you provide a reference or at least give an example?

2) From Martin's review:

Section 5.5 prohibits the use of GET on "/".  This prohibits use of the
resource for other purposes.  It seems reasonable to accept POST messages as
defined in RFC 6546, but this requirement is overly strict (and further
entrenches the violation of RFC 7320).  If, for instance, the server operator
wishes to provide HTML in response to a GET request to "/", this would prohibit
that.  The requirement to return 404 if RFC 6546 is not supported is worse; not
supporting RFC 6546 might be a choice that a deployment makes to avoid the need
to reserve "/" for that protocol.

Alexey: The text in -12 is an improvement, but I think it is still confusing.
Maybe mention something along the lines of Martin's suggestion for the case
when RFC 6546 is not supported (or at least not followed as far as the "/"
resource is concerned).

5.5.  / (forward slash) Resource URL

   If the "/" resource is unsupported, then a request for this resource
   MAY be handled as deemed appropriate by the server.

Nit: You haven't expressed any requirement on implementations here, so use of
MAY does not seem appropriate. What are you actually suggesting here?

3) I think some of the text in 6.1.2 is misleading (or I might be wrong):

   Based on RFC5005 section 3 [RFC5005], link
   elements SHOULD be included in all Feeds to support paging using the
   following link relation types:

   o  "first" - Indicates that the href attribute value of the link
      identifies a resource URI for the furthest preceding page of the
      Feed.

   o  "last" - Indicates that the href attribute value of the link
      identifies a resource URI for the furthest following page of the
      Feed.

   o  "previous" - Indicates that the href attribute value of the link
      identifies a resource URI for the immediately preceding page of
      the Feed.

   o  "next" - Indicates that the href attribute value of the link
      identifies a resource URI for the immediately following page of
      the Feed.

Original definitions of these link relations don't include the word "page". I
should double check with Mark Nottigham, but I think they reference the
next/previous, first/last entry, not page. (And a page may contain several
entries.) If I am correct, I don't think it is Ok to redefine meaning of
existing link relations the way you do.

4) In Section 8.3:

   Registration in the ROLIE URN Parameters registry is via the
   Specification Required policy [RFC8126].  Designated Expert reviews
   should be routed through the MILE WG mailing list.  Failing this, the
   Designated Expert will be assigned by the IESG.

As other people already pointed out, the last 2 sentences are confusing.
Are you trying to say that registration requests must be sent to the MILE
mailing list or that they must be reviewed there? This is actually significant
for IANA workflow.

One possibility is that all requests are sent to the MILE mailing list and then
the designated expert forwards approved requests to IANA. In this case if a
Designated Expert misses a request, IANA wouldn't even know that the requester
is waiting for the Designated Expert.

Another possibility is for all requests to be submitted to IANA directly, then
IANA can track them. IANA might either forward requests to the MILE mailing
list or require that all request being submitted to the MILE mailing list first
before being sent to IANA.

So please clarify.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Recommending use of .well-known was my fault. I am looking forward to further
discussion of this issue. I think the document needs some form of service
discovery (and lack of DNS SRV details is a pity) and discovery of root entry
for ROLIE. So I think some form of .well-known is probably needed.

I am glad you got rid of IRIs. That was one of my discussion points on -11.

I am still concerned that user authentication is under-specified, but I can
live with existing text.

6.2.1.  Use of the "atom:content" Element

   This restricts atomContent in ROLIE to the atomOutofLine forumulation
   presented in[RFC4287].

Typo: formulation

In 6.2.3.  Use of the "rolie:format" Element

   The rolie:format element MAY provide a "schema-type" attribute, which
   is a mime type identifying the format of the schema resource

"mime type" should be either "MIME type" or "media type". The latter is the
preferred term these days. You also need a normative reference to media types,
at least to RFC 2045.

   identified by the "schema-location" attribute.

   The following nominal example shows how these attributes describe the
   format of the content:

<rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"
  version="2.0"
  schema-location=
    "https://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd"
  schema-type-"text/xml"/>

I think you meant "schema-type=" (note you have "-" instead of "=").

In 6.2.3 (on page 17)

   The URI used for the "ns" attribute value MUST be an absolute
   or opaque URI.

What is "opaque" URI? The sentence make it sound as if it is a term, opposite
to absolute URI. Or are you trying to say that non resolvable URNs are Ok here?
I suggest deleting "or opaque" from the above sentence or replacing it with
something clearer.

In 6.2.4.  Use of the rolie:property Element

   Implementations MAY use locally defined and namespaced elements in an
   Entry in order to provide additional information.  Clients that do
   not recognize a property with an unregistered name attribute MAY
   ignore the rolie:property.

The second "MAY": or do what? Should the MAY be changed to a MUST?

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Thu, 26 Oct 2017 14:53:21 +0000

Alexey,

Thanks for the review, comments inline.

Thanks,
Stephen Banghart

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Thursday, October 26, 2017 7:37 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; mile-
> [email-masked]
> Subject: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with
> DISCUSS and COMMENT)
> 
[snip]
> This is a useful document and I will be balloting "Yes" once the following small
> issues are resolved/discussed (some of these come from Martin's ARTART
> review):
> 

Sure. This field is exposing some identifier for the resource in the atom:content element. For example, if the atom:content is linking to an IODEF document, the only way (without this property) for a consumer to learn any identifying information about that document is to download it. 

For the sake of example, lets say that inside that IODEF document is a ID="ID12345" element. In the ROLIE feed, the rolie:property element exposes the ID, so then the rolie:property field would be "name"= "urn:ietf:params:rolie:property:content-id" and value="ID12345".

If this still seems confusing we can rewrite the text in the specification or include an example to clarify.

> 2) From Martin's review:
> 
> Section 5.5 prohibits the use of GET on "/".  This prohibits use of the resource
> for other purposes.  It seems reasonable to accept POST messages as
> wishes to provide HTML in response to a GET request to "/", this would
> prohibit that.  The requirement to return 404 if RFC 6546 is not supported is
> worse; not supporting RFC 6546 might be a choice that a deployment makes
> to avoid the need to reserve "/" for that protocol.
> 
> Nit: You haven't expressed any requirement on implementations here, so
> use of MAY does not seem appropriate. What are you actually suggesting
> here?

This last sentence was meant to be addressing the case where RFC 6546 is not supported. I've removed the normative requirement and updated the sentence:

"If RFC 6546 is unsupported, then a request for the "/" resource may be handled as deemed appropriate by the server."

And to help clarify I have added this sentence to the first paragraph:

"The following requirements apply only to implementations supporting RFC 6546."

Does this address your concerns? I'd like to fully address Martin's original comments, as I agree that restricting the "/" resource on all servers is detrimental.

> entries.) If I am correct, I don't think it is Ok to redefine meaning of existing
> link relations the way you do.

Section 3 ("Paged Feeds") in RFC 5005 defines paged feeds as a set of linked feed documents, where each feed document contains a subset of entries. The explicit wording used in the link relations is as follows:

   o  "first" - A URI that refers to the furthest preceding document in
      a series of documents.

   o  "last" - A URI that refers to the furthest following document in a
      series of documents.

   o  "previous" - A URI that refers to the immediately preceding
      document in a series of documents.

   o  "next" - A URI that refers to the immediately following document
      in a series of documents.

We've swapped in the word "page" instead of "document" in our document, as we felt that "page" made more inherent sense without the context of the rest of RFC 5005. I believe that we have not changed the definition of the link relations in any way, so changing the wording back to the original would not be a huge problem for us if you think it is needed.

> mailing list or that they must be reviewed there? This is actually significant for
> IANA workflow.
> 
> Designated Expert misses a request, IANA wouldn't even know that the
> requester is waiting for the Designated Expert.
> 

Our original intent here was to have IANA receive and track requests, then send the requests to the MILE mailing list, and then if there is no response, fall back to pre-named Designated Experts (the authors). 

We are having trouble correctly putting together text to express this.

> Recommending use of .well-known was my fault. I am looking forward to
> further discussion of this issue. I think the document needs some form of
> service discovery (and lack of DNS SRV details is a pity) and discovery of root
> entry for ROLIE. So I think some form of .well-known is probably needed.
> 
> I am still concerned that user authentication is under-specified, but I can live
> with existing text.
> 

Fixed, thank you.

> preferred term these days. You also need a normative reference to media
> types, at least to RFC 2045.

Changed to media type, and reference added to RFC 2045.

> "https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .iana.org%2Fassignments%2Fxml-registry%2Fschema%2Fiodef-
> 2.0.xsd&data=02%7C01%7Cstephen.banghart%40nist.gov%7C5adedf178b8c4
> ef12b9d08d51c65d567%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7
> C636446146074444836&sdata=kKbwLXchAMCF8Gw%2FQUb8xfq5nClUocI30z
> wO5lK3XWs%3D&reserved=0"
>   schema-type-"text/xml"/>
> 

Fixed, thanks.

> I suggest deleting "or opaque" from the above sentence or replacing it with

I've deleted the "or opaque", as the intent was to disallow relative URIs. I think that the current requirement followed by the last sentence of the paragraph (The resource identified by the URI need not be resolvable.) provide enough information.

> The second "MAY": or do what? Should the MAY be changed to a MUST?

Yes, this was intended to be a MUST. The client MUST NOT fail parsing content that contains an unrecognized property. I changed the keyword to MUST and provided some additional text to clarify:

"The client MUST NOT fail parsing content that
            contains an unrecognized property."

> _______________________________________________
> mile mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghar
> t%40nist.gov%7C5adedf178b8c4ef12b9d08d51c65d567%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636446146074444836&sdata=kgE4ok9Q5Zz
> %2B3suOnaPnESNVDonXUwYn0tQJKXm73i0%3D&reserved=0

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Oct 2017 14:30:40 +0100

Hi Stephen,

> If this still seems confusing we can rewrite the text in the specification or include an example to clarify.
I think giving an example for IODEF would be great. If the value can be 
anything else, it would be good to say that too.

(I was partially confused because Content-ID means something else in 
email, so lack of reference is not helping.)
> Does this address your concerns? I'd like to fully address Martin's original comments, as I agree that restricting the "/" resource on all servers is detrimental.
Works for me.
> We've swapped in the word "page" instead of "document" in our document, as we felt that "page" made more inherent sense without the context of the rest of RFC 5005. I believe that we have not chang…
Let me following with Mark Nottingham on this.
> Our original intent here was to have IANA receive and track requests, then send the requests to the MILE mailing list, and then if there is no response, fall back to pre-named Designated Experts (t…
IANA doesn't track comments, because they lack technical skills to 
evaluate request. So a Designated Expert must always be involved.
> We are having trouble correctly putting together text to express this.
Maybe say something like this:

OLD:

    Designated Expert reviews
    should be routed through the MILE WG mailing list.  Failing this, the
    Designated Expert will be assigned by the IESG.

NEW:
    Registration requests must be sent to both the MILE WG mailing list ([email-masked])
    and IANA. IANA will forward registration requests to the Designated Expert.

Or you can ask IANA if they are happy to just receive and forward all registration requests to [email-masked].

(There is no need to say "Designated Expert will be assigned by the IESG", because this is the default.)

  (snip)
> I've deleted the "or opaque", as the intent was to disallow relative URIs. I think that the current requirement followed by the last sentence of the paragraph (The resource identified by the URI ne…
Agreed.
>              contains an unrecognized property."
Much better, thank you.

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Fri, 27 Oct 2017 17:52:22 +0000

Alexey,

Reponses inline. I've added changes based on your rolie:property comments and your IANA comments. I will wait on Mark's response on RFC 5005 for that section.

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Friday, October 27, 2017 9:31 AM
> To: Banghart, Stephen A. (Fed) <[email-masked]>; Alexey
> Melnikov <[email-masked]>; The IESG <[email-masked]>
> Subject: Re: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12:
> (with DISCUSS and COMMENT)
> 
> Hi Stephen,
> 
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked]; mile- [email-masked]
> >> Subject: [mile] Alexey Melnikov's Discuss on
> >> draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT)
> >>
> >> This is a useful document and I will be balloting "Yes" once the
> >> following small issues are resolved/discussed (some of these come
> >> from Martin's ARTART
> >> review):
> >>
> > Sure. This field is exposing some identifier for the resource in the
> atom:content element. For example, if the atom:content is linking to an
> IODEF document, the only way (without this property) for a consumer to
> learn any identifying information about that document is to download it.
> >
> > For the sake of example, lets say that inside that IODEF document is a
> ID="ID12345" element. In the ROLIE feed, the rolie:property element
> exposes the ID, so then the rolie:property field would be "name"=
> "urn:ietf:params:rolie:property:content-id" and value="ID12345".
> >
> (I was partially confused because Content-ID means something else in email,
> so lack of reference is not helping.)

I've added an example to the section in question to clarify it further:

	"The "value" attribute of this property is a text representation
            of an identifier pertaining to or extracted from the content
            referenced by the "src" attribute of the entry's atom:content
            element. For example, if the atom:entry's atom:content
            element links to an IODEF document, the "content-id"
            value would be an identifier of that IODEF document."

> >> 2) From Martin's review:
> >>
> >> Section 5.5 prohibits the use of GET on "/".  This prohibits use of
> >> the resource for other purposes.  It seems reasonable to accept POST
> >> messages as defined in RFC 6546, but this requirement is overly
> >> strict (and further entrenches the violation of RFC 7320).  If, for
> >> instance, the server operator wishes to provide HTML in response to a
> >> GET request to "/", this would prohibit that.  The requirement to
> >> return 404 if RFC 6546 is not supported is worse; not supporting RFC
> >> 6546 might be a choice that a deployment makes to avoid the need to
> reserve "/" for that protocol.
> >>
> >> Maybe mention something along the lines of Martin's suggestion for
> >> the case when RFC 6546 is not supported (or at least not followed as far as
> the "/"
> >> resource is concerned).
> >>
> >> Nit: You haven't expressed any requirement on implementations here,
> >> so use of MAY does not seem appropriate. What are you actually
> >> suggesting here?
> > This last sentence was meant to be addressing the case where RFC 6546 is
> not supported. I've removed the normative requirement and updated the
> sentence:
> >
> > "If RFC 6546 is unsupported, then a request for the "/" resource may be
> handled as deemed appropriate by the server."
> >
> > Does this address your concerns? I'd like to fully address Martin's original
> comments, as I agree that restricting the "/" resource on all servers is
> detrimental.
> Works for me.
> >> Original definitions of these link relations don't include the word
> >> "page". I should double check with Mark Nottigham, but I think they
> >> reference the next/previous, first/last entry, not page. (And a page
> >> may contain several
> >> entries.) If I am correct, I don't think it is Ok to redefine meaning
> >> of existing link relations the way you do.
> > Section 3 ("Paged Feeds") in RFC 5005 defines paged feeds as a set of
> linked feed documents, where each feed document contains a subset of
> entries. The explicit wording used in the link relations is as follows:
> >
> > We've swapped in the word "page" instead of "document" in our
> document, as we felt that "page" made more inherent sense without the
> context of the rest of RFC 5005. I believe that we have not changed the
> definition of the link relations in any way, so changing the wording back to
> the original would not be a huge problem for us if you think it is needed.
> >> Are you trying to say that registration requests must be sent to the
> >> MILE mailing list or that they must be reviewed there? This is
> >> actually significant for IANA workflow.
> >>
> >> One possibility is that all requests are sent to the MILE mailing
> >> list and then the designated expert forwards approved requests to
> >> IANA. In this case if a Designated Expert misses a request, IANA
> >> wouldn't even know that the requester is waiting for the Designated
> Expert.
> >>
> >> Another possibility is for all requests to be submitted to IANA
> >> directly, then IANA can track them. IANA might either forward
> >> requests to the MILE mailing list or require that all request being
> >> submitted to the MILE mailing list first before being sent to IANA.
> >>
> >> So please clarify.
> > Our original intent here was to have IANA receive and track requests, then
> send the requests to the MILE mailing list, and then if there is no response,
> fall back to pre-named Designated Experts (the authors).
> IANA doesn't track comments, because they lack technical skills to evaluate
> request. So a Designated Expert must always be involved.

Thank you, we have accepted your new text. We'll contact IANA to verify the changes with them.

Thanks,
Stephen

> >> What is "opaque" URI? The sentence make it sound as if it is a term,
> >> opposite to absolute URI. Or are you trying to say that non
> >> resolvable URNs are Ok here?
> >> I suggest deleting "or opaque" from the above sentence or replacing
> >> it with something clearer.
> > I've deleted the "or opaque", as the intent was to disallow relative URIs. I
> think that the current requirement followed by the last sentence of the
> paragraph (The resource identified by the URI need not be resolvable.)
> provide enough information.
> Agreed.
> > Yes, this was intended to be a MUST. The client MUST NOT fail parsing
> content that contains an unrecognized property. I changed the keyword to
> MUST and provided some additional text to clarify:
> >