Subject: Re: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review

From: [email-masked] (Dale R. Worley)
Date: Tue, 6 May 2014 14:53:40 -0400

2014-04-28 14:59 GMT+02:00 Alexey Melnikov <[email-masked]>:
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-salud-alert-info-urns-12.txt
> Reviewer: Alexey Melnikov
> Review Date: 27 April 2014
> IETF LC End Date: 25 April 2014
> IESG Telechat date: (if known) N/A
>
> Summary: Ready with nits/questions.
>
>
> Major issues:
> None
>
> Minor issues:
>
> 13.  User Agent Behaviour
>
>    The User Agent (UA) MUST produce a reasonable rendering regardless of
>    the combination of URIs (of any schemes) in the Alert-Info header
>    field.
>
> This MUST is not well defined to be implementable. How can conformance or
> violation of this requirement can be tested? I suggest you avoid using RFC
> 2119 language here.

The authors agree and will change the MUST to "must".

Because we had another comment regarding this paragraph from our Area
Director (Richard Barnes), we will add following text at the end of
that paragraph:

    In particular, unless the containing message is a request and is
    immediately rejected, the UA SHOULD provide some alert unless it is
    explicitly instructed not to (for example, by Alert-Info URIs that
    it understands, the presence of a Replaces or Joins header field,
    local policy, or direction of the user).

> Has this been submitted to the [email-masked] mailing list for 2
> weeks review? (as per RFC 3406)

The urn-nid review started 3 Oct 2013:
http://www.ietf.org/mail-archive/web/urn-nid/current/msg01218.html
There were no comments.

> Nits/editorial comments:
>
>  "REQ-4: has been deleted.  To avoid confusion, the number will not be
> reused".
>
>  I find this to be rather unusual. Are these requirements used in RFPs?

We did not want a renumbering of the requirements in order to avoid
confusion when people sent comments on the requirements. It makes
sense to renumber the requirements now, and we will do so.

> In Section 7:
>
> date              = [CC] YY [ "-" MM ["-" DD] ]
>
>
> Is there a need for having 2 octet years? Are you trying to save some
> bytes here at the expense of extra (albeit minor) complexity?

We believe it is valuable to allow just YY, but are willing remove it if
necessary to pass the gen-art review.

Overall, we have strived to allow brevity in the date formats.
Allowing CC to be optional changes the number of permitted date
formats from 4 (including complete absence) to 7, but it only
increases the number of distinct choices in code that processes dates
from 3 to 4.  Given that CC can only be "20" for the next 86 years,
and the general desirability of brevity, we think that it is as
reasonable to make CC optional as it is to make MM and DD optional.

Dale [for the authors of draft-ietf-salud-alert-info-urns]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 May 2014 23:38:49 +0000

> > This MUST is not well defined to be implementable. How can 
> conformance 
> > or violation of this requirement can be tested? I suggest you avoid 
> > using RFC
> > 2119 language here.
> 

Can we avoid lower case forms of RFC 2119 language as this just leaves the reader with the question as to whether there was an editing error.

I would suggest "The User Agent (UA) is expected to produce..."

Regards

Keith

> -----Original Message-----
> From: salud [mailto:[email-masked]] On Behalf Of Dale 
> R. Worley
> Sent: 06 May 2014 19:54
> To: Alexey Melnikov; [email-masked]
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [salud] Gen-art LC review of 
> draft-ietf-salud-alert-info-urns-12 and also Area Director's review
> 
> > This MUST is not well defined to be implementable. How can 
> conformance 
> > or violation of this requirement can be tested? I suggest you avoid 
> > using RFC
> > 2119 language here.
> 
> Because we had another comment regarding this paragraph from 
> our Area Director (Richard Barnes), we will add following 
> text at the end of that paragraph:
> 
> > Has this been submitted to the [email-masked] 
> mailing list for 
> > 2 weeks review? (as per RFC 3406)
> 
> We did not want a renumbering of the requirements in order to 
> avoid confusion when people sent comments on the 
> requirements. It makes sense to renumber the requirements 
> now, and we will do so.
> 
> > In Section 7:
> >
> We believe it is valuable to allow just YY, but are willing 
> remove it if necessary to pass the gen-art review.
> 
> Allowing CC to be optional changes the number of permitted 
> date formats from 4 (including complete absence) to 7, but it 
> only increases the number of distinct choices in code that 
> processes dates from 3 to 4.  Given that CC can only be "20" 
> for the next 86 years, and the general desirability of 
> brevity, we think that it is as reasonable to make CC 
> optional as it is to make MM and DD optional.
> 
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 7 May 2014 11:55:09 -0400

[as an author]

> From: "DRAGE, Keith (Keith)" <[email-masked]>
> 
> > > 13.  User Agent Behaviour
> > >
> > >    The User Agent (UA) MUST produce a reasonable rendering
> > >    regardless of the combination of URIs (of any schemes) in the
> > >    Alert-Info header field.
> > >
> > > conformance or violation of this requirement can be tested? I
> > > suggest you avoid using RFC 2119 language here.
> > 
> Can we avoid lower case forms of RFC 2119 language as this just
> leaves the reader with the question as to whether there was an
> editing error.
> 

It's a tricky matter.  What we really want is MUST, that this is a
constraint on the UA, particularly that it must be prepared to cope
with any sequence of syntactically-correct URIs, and it must do
something that is reasonable in the eyes of the user.  The problem is
that this criterion isn't testable in any absolute way, despite the
fact that there are a large number of actions that "everybody" would
agree are violations.

So the Gen-Art reviewer didn't like "MUST".  Unfortunately, he didn't
suggest an alternative.

As far as I can tell, "must" is fairly common in RFCs.  Over half the
RFCs from 6000 to 6999 use "must" (outside of boilerplate language).
Many of them use it in a more-or-less normative way.

RFC 2119 gives this guidance, for what it's worth:

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for

At this time, I prefer "must" over "MUST", but I prefer "MUST" over
"is expected to" or anything that is similarly indirect.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 8 May 2014 16:13:00 -0400

[as an author]

Acting on Ben Campbell's suggestion that we consider revising the
first sentence of section 13 so that it can support a MUST, I've
written a revision:

[In this message, I've separated the three sentences to make
comparisons easier; it is all one paragraph.  I changed "explicitly
instructed" to "instructed" in sentence 3.]

     13.  User Agent Behaviour

     The User Agent (UA) must produce a reasonable rendering
     regardless of the combination of URIs (of any schemes) in the
     Alert-Info header field:

     It MUST produce a rendering based on the URIs that it can
     understand and act on (if any), interpreted as prescribed by
     local policy, and ignore the other URIs.

     In particular, unless the containing message is a request and is
     immediately rejected, the UA SHOULD provide some alert unless it
     is instructed not to (for example, by Alert-Info URIs that it
     understands, the presence of a Replaces or Joins header field,
     local policy, or direction of the user).

What do people think?

I think that sentence 2 is really what we intended by sentence 1.  I
left in sentence 1 to give guidance to the overall idea, while
sentence 2 gives the details.

I included "URIs that it can ... act on", because it's possible that a
UA could receive an http: URI but be unable to fetch its contents, or
be unable to decode the fetched contents.

Of course, sentence 2 allows a lot of latitude for implementations,
because it says "interpreted as prescribed by local policy", but I
think it gives the right effect, because, e.g., I don't think anyone
is willing to say "local policy is that if we can't process a URI, we
will just generate white noise".

In sentence 3, I removed "explicitly" because a number of the listed
factors that "instruct" the UA not to alert aren't really "explicit".

And I found another cause not to alert:  re-INVITEs.  But I didn't add
it to the list, because we already list 5 factors.  Presumably the
implementors will understand that.

However, I think that the fact that we've found another factor shows
that we want this requirement to be a SHOULD.  As it says in RFC 2119:

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 May 2014 20:09:03 -0400

> sentence 2 gives the details.

Sentence 3 is also needed. Sentence 2 doesn't cover the case where none 
of the URNs are understood.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 14 May 2014 15:05:43 -0400

> From: Alexey Melnikov <[email-masked]>

> If you can show some examples (and add them to the text), that would
> be valuable.

The authors are currently discussing rewriting this paragraph (per a
suggestion by Ben Campbell) in order to make it clear what is meant by
"reasonable".  In practice, it seems that the UA must ignore any URIs
that it cannot understand (e.g., unkown schemes) or cannot act on
(e.g., HTTP URIs to non-local destinations), and construct an alert
based on the URIs that it understands and can act on (which of course
would be a default alert if there were no actionable URIs).

> At first I thought this sentence sounded like "you MUST NOT crash",
> which I thought was obvious and not worth stating. But it looks like
> you have something else in mind?

"must not crash" is important.  So is "must produce *some* alert".
The general idea is "Degraded performance is OK; failure to perfrom is
not OK."

Dale