Subject: Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Fri, 25 Jan 2019 16:06:37 +0000

Hi Adam,

Thanks a lot for your feedback. The JSON examples and ipv6 address ranges will be corrected.
Otherwise, see my answer to one of your comments inline,
All the best for 2019,
Sabine

-----Original Message-----
From: Adam Roach <[email-masked]> 
Sent: Thursday, November 29, 2018 3:48 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Gurbani, Vijay (Nokia - US/Naperville) <[email-masked]>; [email-masked]; Gurbani, Vijay (Nokia - US/Naperville) <[email-masked]>; [email-masked]
Subject: Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-alto-cost-calendar-09: 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-alto-cost-calendar/

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

Thanks to everyone who worked on creating this extension. It seems useful, and the document is easy to read. I have a handful of suggestions for improvement.

---------------------------------------------------------------------------

General:

I found a surprising number of JSON errors in this document by casual examination.  Those errors I found are called out below, but it is extremely likely that I have missed some issues. Please run the JSON examples in this document through a formal validation prior to publication.

With a reasonably modern version of nodejs, validation can be as simple as something like:

node -e 'console.log(JSON.stringify(JSON.parse(`
  {
    "meta" : {
      "cost-type" : {"cost-mode" : "numerical",
                     "cost-metric" : "routingcost"},
      "calendar-response-attributes" : [
        {"calendar-start-time" : Mon, 30 Jun 2014 00:00:00 GMT,
         "time-interval-size" : "1 hour",
         "number-of-intervals" : 24,
         "repeated": 4
        }
      ],
    }
    "endpoint-cost-map" : {
      "ipv4:192.0.2.2": {
        "ipv4:192.0.2.89"    : [v1, v2, ... v24],
        "ipv4:198.51.100.34" : [v1, v2, ... v24],
        "ipv4:203.0.113.45"  : [v1, v2, ... v24],
        "ipv6:2000::1:2345:6789:abcd" : [v1, v2, ... v24]
      }
    }
  }
`)));'

Running this example shows the first error in this example, involving the date. After fixing that error, you will find the missing comma. And so on.

---------------------------------------------------------------------------

General:

Please expand "ALTO" in the title, in the Abstract, and on first use in the body of the document.
[[SR]] DONE

---------------------------------------------------------------------------

§6:

>  [RFC7285] ensures the availability of such a solution in its  Section 
> 8.3.5.  "Authentication and Encryption", which specifies that  "ALTO 
> server implementations as well as ALTO client implementations  MUST 
> support the "https" URI scheme [RFC2818] and Transport Layer  Security 
> (TLS) [RFC5246]".

Based on this guidance, I would encourage updating all instances of "http://" in this document to instead be "https://". I count four such instances.
[[SR]] DONE

---------------------------------------------------------------------------

§1:

>  In this draft an "ALTO Cost Calendar" is specified by information  
> resources capabilities that are applicable to time-sensitive ALTO  
> metrics.  An ALTO Cost Calendar exposes ALTO Cost Values in JSON

Please cite RFC 8259.
[[SR]] DONE

---------------------------------------------------------------------------

§4.1.3:

>        "calendar-response-attributes" : [
>          "calendar-start-time" : Tue, 1 Jul 2014 13:00:00 GMT,
>          "time-interval-size" : "2 hour",

Nit: The value for calendar-start-time needs to be enclosed in quotation marks.

       "cost-map" : {
         "PID1": { "PID1": [v1,v2, ... v12],
                   "PID2": [v1,v2, ... v12],
                   "PID3": [v1,v2, ... v12] },
         "PID2": { "PID1": [v1,v2, ... v12],
                   "PID2": [v1,v2, ... v12],
                   "PID3": [v1,v2, ... v12] }
       }

I don't quite follow this closely enough to understand what is intended here, but the naked 'v1,v2' in the arrays are not valid JSON. Assuming these are literal values, they need to each be enclosed in quotation marks.

Both of these comments apply to the examples given in §4.2.3 and §4.2.3 as well.

[[SR]] The purpose is actually to lighten the reading. Would the following addition to paragraph 3 of section 4.1.3 be OK ?
"The Server returns Calendars with arrays of 12 numbers. To lighten the text, the arrays in the provided example are symbolized by expression "[v1,v2, ... v12]" that is otherwise not valid in JSON. The same type of symbolization is used in the example Server responses."

---------------------------------------------------------------------------

§4.2.3:

>       "ipv6:2000::1:2345:6789:abcd"

Please use an address from the range reserved by RFC 3489.

This comment applies to the example given in §4.2.4 as well.

>   }
>   "endpoint-cost-map" : {

There is a missing comma after the closing brace.

---------------------------------------------------------------------------

§4.2.4:

>     "calendar-response-attributes" : [
>       {"cost-type-name : num-routingcost"

Nit: This line is missing two quotation marks and a comma. It should be:

        {"cost-type-name" : "num-routingcost",

---

From: Adam Roach <[email-masked]>
Date: Fri, 25 Jan 2019 15:25:18 -0600

> "The Server returns Calendars with arrays of 12 numbers. To lighten the text, the arrays in the provided example are symbolized by expression "[v1,v2, ... v12]" that is otherwise not valid in JSON.…

That seems a reasonable approach. Thanks!

/a

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 29 Jan 2019 17:53:06 +0000

Hi Adam and Benjamin,

Regarding the citation of RFC 8259, in the Introduction, using the JSON format as specified in RFC 8259 may actually cause backwards compatibility issues with RFC7285 that uses the JSON format specified in RFC7159. Would it be OK to cite 7159 in the Introduction and add the paragraph below in section 2.2.2 “Compatibility with legacy ALTO Clients" ?

Thanks,
Sabine

<t>Last, for backwards compatibility with <xref target="RFC7285"/>, 
          this extension encodes its requests and responses using the JSON 
          Data Interchange Format specified in <xref target="RFC7159"/>. 
          The latter has been obsoleted by <xref target="RFC8259"/>, 
          that among others makes UTF-8 mandatory for text encoding to 
          improve interoperability. Therefore, Clients and Servers supporting 
          ALTO Calendars SHOULD use UTF-8 for text encoding while still being able to 
          successfully read texts in other encodings such as UTF-16 and UTF-32.</t>

-----Original Message-----
From: Adam Roach <[email-masked]> 
Sent: Friday, January 25, 2019 10:25 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; Gurbani, Vijay (Nokia - US/Naperville) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

/a

---

From: Kai GAO <[email-masked]>
Date: Wed, 30 Jan 2019 02:52:32 +0800

Hi Adam and Benjamin,

It appears to me that the JSON format is not specific to the cost calendar
but a general problem with all ALTO extensions (or even all protocols
encoded in JSON).

I wonder if we have some kind of "best practice" in situations like this.
For example, how do other protocols handle this if they originally cited
RFC 7159?

Since you guys are more senior in the IETF, do you happen to know any RFC
in a similar situation? I think that would be extremely helpful so we don't
have to get into this fight for other on-going ALTO drafts.

Many thanks!

Best,
Kai

On Wed, Jan 30, 2019 at 1:53 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <[email-masked]> wrote:

> Hi Adam and Benjamin,
>
> Regarding the citation of RFC 8259, in the Introduction, using the JSON
> format as specified in RFC 8259 may actually cause backwards compatibility
> issues with RFC7285 that uses the JSON format specified in RFC7159. Would
> it be OK to cite 7159 in the Introduction and add the paragraph below in
> section 2.2.2 “Compatibility with legacy ALTO Clients" ?
>
> Thanks,
> Sabine
>
> To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> [email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; Gurbani, Vijay (Nokia -
> US/Naperville) <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: Adam Roach's No Objection on
> draft-ietf-alto-cost-calendar-09: (with COMMENT)
>
> > [[SR]] The purpose is actually to lighten the reading. Would the
> following addition to paragraph 3 of section 4.1.3 be OK ?
> > "The Server returns Calendars with arrays of 12 numbers. To lighten the
> text, the arrays in the provided example are symbolized by expression
> "[v1,v2, ... v12]" that is otherwise not valid in JSON. The same type of
> symbolization is used in the example Server responses."
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 29 Jan 2019 13:30:24 -0600

On 1/29/19 12:52 PM, Kai GAO wrote:
> Hi Adam and Benjamin,
>
> It appears to me that the JSON format is not specific to the cost 
> calendar but a general problem with all ALTO extensions (or even all 
> protocols encoded in JSON).
>
> I wonder if we have some kind of "best practice" in situations like 
> this. For example, how do other protocols handle this if they 
> originally cited RFC 7159?

I can't offhand think of a protocol in a similar situation regarding 
JSON. In other similar cases, the course of action has been somewhat 
dependent on the nature of the changes between an older draft and a 
draft that obsoletes it. In many cases, changes are 
backwards-compatible, and I think there's an implicit assumption that 
new implementations will automatically make use of the newer document.

In other cases where there have been breaking changes, I've seen working 
groups issue new clarification documents to "clean up" the discrepancy. 
For example, when RFC 6665 replaced RFC 3265, the SIPCORE working group 
created RFC 7647 to clarify the impact of those changes on RFC 3515. It 
wouldn't be unreasonable for ALTO to do something similar.

> Since you guys are more senior in the IETF, do you happen to know any 
> RFC in a similar situation? I think that would be extremely helpful so 
> we don't have to get into this fight for other on-going ALTO drafts.

The decision made by the JSON working group when creating RFC 8259 was 
that the practice of trying to deal with multiple encodings was 
problematic from an interoperability perspective, and that practical 
interoperability is best achieved by always using UTF-8. The RFC itself 
attempts to capture this rationale:

>     Previous specifications of JSON have not required the use of UTF-8
>     when transmitting JSON text.  However, the vast majority of JSON-
>     based software implementations have chosen to use the UTF-8 encoding,
>     to the extent that it is the only encoding that achieves
>     interoperability.

A decision by the ALTO working group to intentionally use an obsoleted 
version of JSON puts it in the position of reverting consensus 
established by the JSON working group. While this kind of consensus 
revision is possible in the IETF, it needs to be part of the charter of 
the working group that is doing it. Given that ALTO is not chartered to 
revise JSON procedures, this isn't allowable.

If you wanted to normatively cite RFC 8259 and then include 
non-normative text indicating that it is possible that older data might 
be written in UTF-16 or UTF-32, and that implementations might want a 
configuration option that allows reading such formats, I think that 
would be keeping in the spirit of the "part of a closed ecosystem" 
language in RFC 8259.

/a

---

From: Kai GAO <[email-masked]>
Date: Wed, 30 Jan 2019 12:44:43 +0800

Hi Adam,

Thanks for the clarification. Regarding the situation, I wonder if the
following procedure makes sense:

1. Extensions of the ALTO protocol should not explicitly cite a specific
(especially the obsoleted) JSON RFC but "follow the same JSON format as in
the base protocol (RFC 7285)".
2. Charter a draft to clarify the impacts of new JSON (and probably TLS
too) standards on all ALTO-related RFCs.

Or maybe we should have a standard paragraph stating the situation and put
it in every ALTO extension?

What do you think?

Best,
Kai

On Wed, Jan 30, 2019 at 3:30 AM Adam Roach <[email-masked]> wrote:

> I can't offhand think of a protocol in a similar situation regarding JSON.
> In other similar cases, the course of action has been somewhat dependent on
> the nature of the changes between an older draft and a draft that obsoletes
> it. In many cases, changes are backwards-compatible, and I think there's an
> implicit assumption that new implementations will automatically make use of
> the newer document.
>
> groups issue new clarification documents to "clean up" the discrepancy. For
> example, when RFC 6665 replaced RFC 3265, the SIPCORE working group created
> RFC 7647 to clarify the impact of those changes on RFC 3515. It wouldn't be
> unreasonable for ALTO to do something similar.
>
>
> that the practice of trying to deal with multiple encodings was problematic
> from an interoperability perspective, and that practical interoperability
> is best achieved by always using UTF-8. The RFC itself attempts to capture
> this rationale:
>
>
> version of JSON puts it in the position of reverting consensus established
> by the JSON working group. While this kind of consensus revision is
> possible in the IETF, it needs to be part of the charter of the working
> group that is doing it. Given that ALTO is not chartered to revise JSON
> procedures, this isn't allowable.
>
> If you wanted to normatively cite RFC 8259 and then include non-normative
> text indicating that it is possible that older data might be written in
> UTF-16 or UTF-32, and that implementations might want a configuration
> option that allows reading such formats, I think that would be keeping in
> the spirit of the "part of a closed ecosystem" language in RFC 8259.
>
> /a
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 30 Jan 2019 10:13:22 -0600

> it in every ALTO extension?

This seems to be sidestepping the key question, of whether UTF-8 is
actually the de facto interoperable JSON encoding for ALTO usage, or
whether there is nontrivial usage of other encodings.  It seems a little
odd to consider procedural options without knowing what the right answer
is.

-Benjamin

---

From: Kai GAO <[email-masked]>
Date: Thu, 31 Jan 2019 05:29:22 +0800

Hi Benjamin,

Thanks for the reply.

DISCLAIMER: I'm only speaking on behalf of myself.

Well, the situation is that we don't know the answer to the key question at
the moment and probably also in the near future.
Thus, the problem at hand is "how do we proceed if we don't know the
answer".
My personal opinion is that ALTO should be self-contained so the principle
is that extensions should not conflict with the base protocol.
So instead of patching every draft, why don't we just patch the root cause
(RFC 7285)?

However, I don't really know if this is the best practice in IETF.
Since you and Adam are the experts here, we would like very much to
leverage your expertise a bit and hear your opinions on this procedural
problem.
(I imagine the implication is that we should not proceed until we find out
the answer?)

Back to the encoding. If UTF-8 is the de facto JSON encoding in JSON
libraries, as Adam pointed out, I don't see why it would not be for ALTO
usage.
I don't truly believe there would be a nontrivial amount of developers who
use an 18-century JSON library or reinvent the wheel just to be
interoperable with ALTO.

Just my 2 cents.

Best,
Kai

---

From: Vijay Gurbani <[email-masked]>
Date: Wed, 30 Jan 2019 16:26:52 -0600

Well, procedurally speaking, if we want to fix the root cause (RFC 7285), I
suspect that we can do so through a RFC that modifies RFC 7285.  Related
questions like how quick can we do that, is it in our charter and if not
how to proceed, etc. are questions that can be attended to once the WG
decides that modifying RFC 7285 would be the best course of action.

Do I get the sense that the WG thinks that this is the best course of
action?  (I must apologize as I am coming up to speed on this issue.  If I
was to produce a 1 sentence summary of the issue here, it is that RFC 8259
normatively requires UTF-8 encoding and that there are existing ALTO
implementations conformant to RFC 7285 that use encodings other than
UTF-8.  Is that accurate?).

Thanks,

- vijay

On Wed, Jan 30, 2019 at 3:29 PM Kai GAO <[email-masked]> wrote:

> Well, the situation is that we don't know the answer to the key question
> at the moment and probably also in the near future.

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Jan 2019 17:37:34 -0600

On 1/30/19 4:26 PM, Vijay Gurbani wrote:
> action?  (I must apologize as I am coming up to speed on this issue.  
> If I was to produce a 1 sentence summary of the issue here, it is that 
> RFC 8259 normatively requires UTF-8 encoding and that there are 
> existing ALTO implementations conformant to RFC 7285 that use 
> encodings other than UTF-8.  Is that accurate?).

That's my understanding, modulo any other JSON changes you might want to 
highlight. Again, I think RFC 7647 provides a good example of how this 
kind of thing can be clarified.

/a

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 31 Jan 2019 14:30:39 +0000

Hello,

I would personally opt for a Clarification draft for implementing RFC 7285 with RFC 8259. 
Before we get there, the calendar specification may pave the way by making the use of UTF-8 to encode text sent by Calendar-aware Clients and Servers a MUST,  rather than a SHOULD as the proposed text in my previous e-mail suggested. Please see below the new text proposed for the backwards compatibility section. The MUST rule on UTF8 encoding will be distributed in the spec sections. 

We may add this to the operation considerations as well, and mention the possibility of a future clarification on RFC 7285 to make compliance with RFC 8259 mandatory. 

Thanks, 
Sabine

          ALTO Calendars MUST use UTF-8 for text encoding while still being able to 

-----Original Message-----
From: Adam Roach <[email-masked]> 
Sent: Thursday, January 31, 2019 12:38 AM
To: Vijay Gurbani <[email-masked]>; Kai GAO <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

> encodings other than UTF-8.  Is that accurate?).

That's my understanding, modulo any other JSON changes you might want to highlight. Again, I think RFC 7647 provides a good example of how this kind of thing can be clarified.

/a

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 31 Jan 2019 09:17:47 -0600

Adam, thanks for confirming.

Sabine, very well.  The IESG can look at your suggested changes and proceed
accordingly.

In the meantime, I think we should open up a thread in the ALTO WG (so we
don't disturb the IESG further with this issue) and reach consensus how to
proceed forward.  I will do so later today.

Thank you, all.

On Thu, Jan 31, 2019 at 8:30 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <[email-masked]> wrote:

> Before we get there, the calendar specification may pave the way by making
> the use of UTF-8 to encode text sent by Calendar-aware Clients and Servers
> a MUST,  rather than a SHOULD as the proposed text in my previous e-mail
> suggested. Please see below the new text proposed for the backwards
> compatibility section. The MUST rule on UTF8 encoding will be distributed
> in the spec sections.
>
> We may add this to the operation considerations as well, and mention the
> possibility of a future clarification on RFC 7285 to make compliance with
> RFC 8259 mandatory.
>
> Thanks,
> Sabine
>
> Cc: Benjamin Kaduk <[email-masked]>; Randriamasy, Sabine (Nokia -
> FR/Paris-Saclay) <[email-masked]>; The IESG <
> [email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [alto] Adam Roach's No Objection on
> highlight. Again, I think RFC 7647 provides a good example of how this kind
> of thing can be clarified.
>
> /a
>
>