Re: [alto] Finalizing draft-ietf-alto-cdni-request-routing-alto

[Jensen Zhang]

Hi Kevin and Sanjay,

Thank you so much for the reviews. Please see my comments inline.

On Sun, Jan 5, 2020 at 2:42 PM Kevin Ma  wrote:

> Hi Jan,
>
>   Sorry for the delayed response.  My comments as a co-author and CDNI
> reviewer are below.  Sanjay Mishra has also volunteered to provide an
> independent CDNI review.
>
> thanx!
>
> --  Kevin J. Ma
>
> - section 3.7.1:
>   "one CDNI FCI resource depending on a network map, one filtered CDNI FCI
> resource to be defined in Section 5," -> "one filtered CDNI FCI resource to
> be defined in Section 5, one CDNI FCI resource depending on a network map,"
>  or change the order in the json example
>

Thanks for catching it! Fixed.


>
>   why do the filtered-cdnifci-property-map countrycode and asn
> capabilities not have my-default-network-map.pid properties?
>

It is not reasonable to define my-default-network-map.pid properties of
countrycode or asn entities. In the base ALTO protocol (RFC7285), a PID is
defined as an aggregation of endpoint addresses. So in this example, this
ALTO server does not allow any client to request such mappings from the
filtered-cdnifci-property-map resource.


>
>   in update-my-cdni-fci, for the my-filtered-cdnifci capability,
> ""application/merge-patch+jso" should be ""application/merge-patch+json"
>

Fixed. Thanks!


>
> - section 3.7.3:
>   is this intended to be a continuation of the example in 3.7.2?  if so,
> should "http/2" be in the 3.7.2 example, if it's being removed in 3.7.3?
>  specifically, should "http/2" be "https/1.1" in 3.7.3?
>

Good point! The examples should be revised.


>
>   in the footprint example, should the "value": "ipv4:192.0.2.0/24
> " be a footprint object, i.e., "{ "footprint-type":
> "ipv4", "footprint-value": ["192.0.2.0/24"] } ?  (same comment applies to
> the example in 5.7.3)
>

Yes, it should. Fixed.


>
>   when adding a new ipv4 footprint, does this assume that there was not
> previously an ipv4 footprint defined?  if there was a previously defined
> ipv4 footprint, the update should change the footprint-value array in the
> ipv4 footprint structure?
>

Yes, it will change the footprint-value array. Assuming the "ipv4"
footprint-type is the first footprint object, we should use the following
JSON patch to do the update

{ "op": "add",
  "path": "/cdni-fci/capabilities/0/footprints/0/footprint-value/-",
  "value": "192.0.2.0/24" }

The authors will fix it.


>
> - section 6.2.4:
>   the update of "ipv4:192.0.2.0/24" delivery protocol from "http/1.1" to
> "http/1.1" doesn't actually change anything?
>

Good catch. The values in Sec 6.2.3 and Sec 6.2.4 should be different.
Fixed.


>
> - section 7.1:
>   should probably add some text asking IANA to add the entry to the "CDNI
> Metadata Footprint Types" registry, and add a link to its definition in
> section 4.1.
>

I agree. WIll do it.


>
> - authors:
>   probably should change my email to: kevin.j.ma.i...@gmail.com and
> remove my Ericsson affiliation?
>

No problem. Will update.


>
> nits:
>
> - section 1:
>   "On a high level" -> "At a high level"
>   "; (2) redirecting" -> "; and (2) redirecting"
>   "; (2) CDNI" -> "; and (2) CDNI"
>   "are already in [RFC8008]" -> "are already defined in [RFC8008]"
>
> - section 2.1:
>   "look like" -> "look"
>   "asn and countrycode" -> "asn, and countrycode"
>   "a /32 for IPv4 and a /128 for IPv6" -> "a /32 for IPv4 or a /128 for
> IPv6"
>   "; (5) Capabilities" -> "; and (5) Capabilities"
>
> - section 2.2:
>   "have difficulty to measure" -> "have difficulty measuring"
>   "downstream CDN" -> "dCDN"
>   "QoS" -> "quality of service" ?
>   "cost map from dCDN" -> "cost map from the dCDN"
>   "therefore redirect requests to dCDN" -> "redirect requests to a dCDN"
>   "an upstream CDN" -> "a uCDN"
>   "e.g. " -> "e.g., "
>
> - section 3.5:
>   "The future documents" -> "Future documents"
>
> - section 3.7.2:
>   "delivery protocol and https/1.1" -> "delivery protocol, and https/1.1"
>
> - section 5:
>   "constrains" -> "constraints"
>   "only if the entry contains at least one of the client given
> capabilities will it be returned to the client" -> "an entry will only be
> returned to the client if it contains at least one of the client given
> capabilities"
>
> - section 5.7.2:
>   "only http/1.1 delivery protocol" -> "only the http/1.1 delivery
> protocol"
>
> - section 7.2/7.3:
>   remove "Besides, "
>
> - section 8:
>   "to run out of" -> "to unnecessarily consume"
>   "above well.  However," -> " above, however,"
>   "should not have to served by" -> "should not have to be served by"
>   "dCDN and it may not disclose" -> "dCDN; and it SHOULD not disclose"
>   "a dCDN may consider" -> "a dCDN could consider"
>   "And it needs to avoid expoing" -> "A dCDN SHOULD avoid exposing"
>

Fixed. Thanks for all the grammar check.

Thanks again for the reviews. I did not see any major issues attacking the
current design. The authors will fix all the issues above and submit a new
versio

Re: [alto] Chair review of draft-ietf-alto-incr-update-sse-17

[Vijay Gurbani]

Very well, please do file a request for agenda items once the email goes
out for Vancouver. Thanks.

On Wed, Jan 8, 2020, 7:06 AM Hans Seidel  wrote:

> Hi Vijay,
>
> perfect. I am looking forward to present in Vancouver. Among
> implementation insights, we also happily share information about lessons
> learned and rolling out ALTO with partners.
>
> I will file an agenda request for the Vancouver session once asked for on
> the list.
>
> Thanks,
> Hans
> On 07.01.20 17:35, Vijay Gurbani wrote:
>
> Dear Hans: Thank you for your email.  At this point, I am interested in
> getting as much information about the implementation of the Internet-Draft
> as possible in preparation for moving the work ahead in the WG.  Certainly,
> I will be happy to allocate you some agenda time in Vancouver to document
> any lessons learned on implementing alto-sse.  If you are interested,
> please let me know.
>
> If anyone else on the list has any implementation of alto-sse, please let
> me know as well.
>
> Thanks,
> - vijay
>
> On Tue, Jan 7, 2020 at 10:26 AM Hans Seidel  wrote:
>
>> Hi Vijay,
>>
>> let me answer this question for Ingmar. Currently implemented is the JSON
>> merge patch feature. JSON patch is on our roadmap. We aim for a release
>> that is fully compatible with the latest draft prior to the Vancouver IETF
>> which I also plan to attend. Once the RFC is published, we are going to use
>> SSE in production with our partners.
>>
>> If you or somebody on the list has an ALTO implementation and is
>> interested in running tests, feel free to contact us.
>>
>> If you like to know more, feel free to ask. We also happily give further
>> insights in our SSE implementation, or our ALTO implementation in general
>> in Vancouver. If you or the list is interested in specific parts, please
>> let us know and we prepare some slides for Vancouver.
>>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Chair review of draft-ietf-alto-incr-update-sse-17

[Hans Seidel]

Hi Vijay,

perfect. I am looking forward to present in Vancouver. Among 
implementation insights, we also happily share information about lessons 
learned and rolling out ALTO with partners.


I will file an agenda request for the Vancouver session once asked for 
on the list.


Thanks,
Hans

On 07.01.20 17:35, Vijay Gurbani wrote:
Dear Hans: Thank you for your email.  At this point, I am interested 
in getting as much information about the implementation of the 
Internet-Draft as possible in preparation for moving the work ahead in 
the WG.  Certainly, I will be happy to allocate you some agenda time 
in Vancouver to document any lessons learned on implementing 
alto-sse.  If you are interested, please let me know.


If anyone else on the list has any implementation of alto-sse, please 
let me know as well.


Thanks,
- vijay

On Tue, Jan 7, 2020 at 10:26 AM Hans Seidel > wrote:


Hi Vijay,

let me answer this question for Ingmar. Currently implemented is
the JSON merge patch feature. JSON patch is on our roadmap. We aim
for a release that is fully compatible with the latest draft prior
to the Vancouver IETF which I also plan to attend. Once the RFC is
published, we are going to use SSE in production with our partners.

If you or somebody on the list has an ALTO implementation and is
interested in running tests, feel free to contact us.

If you like to know more, feel free to ask. We also happily give
further insights in our SSE implementation, or our ALTO
implementation in general in Vancouver. If you or the list is
interested in specific parts, please let us know and we prepare
some slides for Vancouver.



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto