Subject: Re: [Captive-portals] Comments/Queries on draft-ietf-capport-api

From: Tommy Pauly <[email-masked]>
Date: Mon, 22 Oct 2018 10:50:59 -0700

Hi Subash,

Thanks for reading the document! To respond to the individual comments:

1. Access to the Internet is indeed an example, but it is among the most reliable ways to distinguish a "captive" network from a "non-captive" network. Captive networks often do also allow access to walled-garden services, at varying levels of authentication and payment. From the architecture document:

Captive Network: A network which limits communication of attached
   devices to restricted hosts until the user has satisfied Captive
   Portal Conditions, after which access is permitted to a wider set of
   hosts (typically the internet).

2. Enforcement is referring to section 2.4 of the architecture document: https://tools.ietf.org/html/draft-ietf-capport-architecture-02#section-2.4

3. How would you expect the request/response to be different? That's assumed to be the request/response used within the TLS connection.

Thanks,
Tommy

> On Jul 16, 2018, at 4:09 PM, Tirupachur Comerica, Subash <[email-masked]> wrote:
> 
> Hi Tommy/Darshak,
> Greetings!
>  
> I was going through the latest update of this draft and had the following questions/observations:
> 1) In the Introduction excerpt:
> The state of captivity (whether or not the host has access to the Internet) - Here I believe Internet is just an example, it could be access to any network, am I correct?
> 2) Is there any other reference that talks about Enforcement under section 2?
> 3) I found the example in section :3.3 was actually showing a HTTP request instead of HTTPS, while sections 2 and 3.1.1 strongly emphasizes HTTPS/authentication for both API server and portal.
>  
> Thanks,
> Subash
>  
> From: Kyle Larose <[email-masked] <mailto:[email-masked]>>
> Date: Friday, July 6, 2018 at 10:48 AM
> To: "Tirupachur Comerica, Subash" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Subject: Re: Comments/Queries on draft-ietf-capport-architecture
>  
> Thanks again for the input! 
>  
> That's a good point about HTTPS vs HTTP. The document should never mention HTTP as part of the solution.
>  
> On 6 July 2018 at 13:43, Tirupachur Comerica, Subash <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Kyle,
> Thanks for CC’ing the right alias.
> The draft seems to use HTTP / HTTPS interchangeably, maybe we should just stick with HTTPS then, to ensure the TLS protects the API server?
> For example, the abstract says HTTP:
>    This document aims to document consensus on the CAPPORT architecture.
>    DHCP or Router Advertisements, an optional signaling protocol, and an
>    HTTP API are used to provide the solution.  The role of Provisioning
>    Domains (PvDs) is described.
>  
> I agree that the functionality bundling is a design decision and may not be architectural.
> I still haven’t completely gone through the API draft you mention in II) below. I may come back to you on this for questions, inputs, if any.
>  
> Thanks again for the quick turn-around.
>  
> Thanks,
> Subash
>  
>  
> From: Kyle Larose <[email-masked] <mailto:[email-masked]>>
> Date: Friday, July 6, 2018 at 4:46 AM
> To: "Tirupachur Comerica, Subash" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> Subject: Re: Comments/Queries on draft-ietf-capport-architecture
>  
> Hi Subash,
>  
> captive-portals is the publicly archived list. I've copied it. I'll respond to your question inline.
>  
> For those on the list who haven't seen this yet, please read my previous reply. I had some thoughts related to the API in it.
>  
> On 5 July 2018 at 19:54, Tirupachur Comerica, Subash <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Kyle,
> Thanks for your response.
> BTW, do you know if this is the right alias that gets archived? Otherwise can you please include the right alias?
>  
> Thanks for your responses.
> I have a follow-up question.
> 1)       Was it considered to provide two URIs during provisioning, one for Server API and another for the actual web-portal, because that way it becomes more tough to break two systems to masquerade an end-user?
> 
> I don't think we ever seriously considered it. 
>  
> a.       In the current design, with just 1 URI returned during provisioning, dns-spoofing the Server API URI and returning an eavesdropping web-portal can gather legitimate login/password.
> 
> Would this not lead to a failure to validate the tls certificate of the malicious server? From the document:
>  
> "
>    The API MUST use TLS for privacy and server authentication.  The
>    implementation of the API MUST ensure both privacy and integrity of
>    any information provided by or required by it.
> "
> b.       Secondly, may be, the API server may also send the Signal, which is kept separate from the web-portal. I definitely like the word authenticity(that is mentioned below) and in this architecture, a single authenticity check for API server and Signal combo would suffice. However, this is bundling(co-hosting) the functionality of Signaling to the API Server.
> 
> The Enforcement Device is logically responsible for triggering the signal, since it is the device which actually devices whether to block or allow traffic. That said, there is no reason it could not relay it through the API server. Or, the API server could also be the enforcement device.  However, those are design decisions for the protocol or deployment; I wouldn't want to tie down the options in the architecture. As you've noted it'd couple the functionality.  This is certainly an option to consider when we design the protocol!
>  
> But then, if the DHCP server is compromised, nothing much can be done.
>  
> Thanks,
> Subash
>  
> From: Kyle Larose <[email-masked] <mailto:[email-masked]>>
> Date: Tuesday, July 3, 2018 at 5:51 PM
> To: "Tirupachur Comerica, Subash" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Subject: Re: Comments/Queries on draft-ietf-capport-architecture
>  
> Thanks for the detailed feedback, Subash. I'll respond inline.
>  
> On 2 July 2018 at 02:40, Tirupachur Comerica, Subash <[email-masked] <mailto:[email-masked]>> wrote:
> Dear Authors,
> 
> I was reviewing the new version of the draft and had the following queries/comments.
> 
> I)
> 
> In the excerpt below, isn’t it the network that decides the policy rules to configure the default route on the user equipment and not the user equipment’s operating system?
> 
> MAY restrict application access to networks not granting full
> 
>       network access.  E.g., a device connected to a mobile network may
> 
>       be connecting to a WiFi network; the operating system MAY avoid
> 
>       updating the default route until network access restrictions have
> 
>       been lifted (excepting access to the Captive Portal server).  This
> 
>       has been termed "make before break".
> 
>  
> 
>  
> A device may be connected to two independently managed networks, so at some point it will be faced with the decision to choose one over the other, particularly for cases where both networks advertise a default route. Consider the common case of a mobile device connected to 4G. It is using that connection for all of its IP communication. Now consider that same device entering into the range of a known wifi hostpot. The hotspot is going to tell the device that it may be used as its default route. Which should the device choose? My understanding is that typically the OS will favour wifi networks over mobile networks, since wifi tends not to be metered, and is often faster. 
>  
> What this point is trying to capture is that the OS will first try to determine whether the wifi network actually has network connectivity prior to changing its routes. This prevents existing connections from needlessly breaking if you've wandered into range of a broken/misconfigured/etc network.
>  
> II)
> 
> In the excerpt below, sorry I could not clearly get if you meant the DHCP server or the web-server serving the captive portal page?
> 
> What exactly is the Accept field here, I didn’t find any mention in RFC 7710 as well.
> 
>  
> 
> For backwards compatibility, it is
> 
>    RECOMMENDED that the server check the "Accept" field when serving the
> 
>    URI , and serve HTML pages for "text/html" and serve the API for
> 
>    "application/json".  [REVISIT: are these details appropriate?]
> 
>  
> 
>  
> This is talking about the web-server (aka the API).
>  
> We actually discussed this at IETF 101 if I remember correctly. The idea is that the client indicates in its http request accept header (https://tools.ietf.org/html/rfc2616#section-14.1 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2616%23section-14.1&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7Cec3104d8533b406e590d08d5e1483747%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=I8ZnWtBFvDGJaHs8GkVMw6Ce3wEplIZ6M52tk8ohvmY%3D&reserved=0>) what type of content the client expects. A legacy client would likely request text, and they certainly would not request json. Thus, by serving up a standard html page for the text/html case, we maintain backwards compatibility. On the other hand, for modern clients, which will request application/json, we can serve up the API.
>  
> That said, there are two issues here for sure:
>  
> 1. The most recent API doc (https://tools.ietf.org/html/draft-ietf-capport-api-01 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-api-01&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7Cec3104d8533b406e590d08d5e1483747%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=TDrVeMfhSlUgqK7NlZFNHN7XGtyAqJPaKNvCFN5cSWc%3D&reserved=0>) uses application/json-capport, so at the very least we need to update this\
> 2. I don't see anything about accepting text to fall back to html in the api doc.
>  
> Ultimately, it feels to me like the architecture is providing too much detail--it should simply recommend some form of backwards compatibility mechanism, and some other document should specify the details of *how* to provide that backwards compatibility. On the other hand, it doesn't seem like we've provided this mechanism in the API so far.
>  
> Does anyone remember what we concluded here at IETF 101? :) I don't see anything in the minutes.
> III) Minor typos here:
> 
> 3.  User Equipment Identity
> 
>  
> 
>    Multiple components in the architecture interact with both the User
> 
>    Equipment and each other.  Since the User Equipment is the focus of
> 
>    these interactions, the components must be able to both identify the
> 
>    user equipment from their interactions with it, and be able to agree
> 
>    on the identifty of the user equipment when interacting with each
> 
>    other.
> 
>  
> Whoops! I even ran it through a spell check. Must have missed that one. :) 
>  
> 
> 3.2.3.  Visible to the API
> 
>  
> 
>    Since the API will need to perform operations which rely on the
> 
>    identifty of the user equipment, such as query whether it is captive,
> 
>    the API needs to be able to relate requests to the User Equipment
> 
>    making the request.
> 
>  
> 
> *sigh* 
>  
> 
> IV) For this step, how do you verify the plausibility(I guess it includes authenticity, integrity)?
> 
> 5.  The User Equipment verifies the signal is plausible.
> 
>  
> 
>  
> It's not really well defined yet, since we haven't specified the signal. That said, we were considering signing the packet somehow, IIRC, or putting some hint that would be relatively hard to spoof if not on-path.
>  
> Perhaps authenticity is a better term?
>  
> Either way, the signal currently specifies these requirements, and now that I  read them or the Nth time, it seems like we're not doing a good job of suggesting that the signal allow for validation/verification:
>  
>  
>    3.  The protocol SHOULD have a method of identifying the source of
>        signals.
>  
>    4.  The signal SHOULD NOT include any information other than a prompt
>        to contact the API, and any information necessary for validation.
>  
> 
> Do we really need to identify the source of the signals? Not unless the validation mechanism requires it. So, I think that #3 should be rephrased along the lines of:
>  
> "The protocol SHOULD have a method of validating that signals were sent by an enforcement device on the user equipment's path to the external network." (That last bit may be unnecessary... Trying to capture what it means for the signal to be valid)
>  
> Thanks,
> 
> Subash Tirupachur Comerica
> 
> Ruckus Networks(An Arris Company)
> 
>  
> 
> On 6/30/18, 5:04 AM, "IETF Secretariat" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
>     
> 
>     Hello,
> 
>     
> 
>     This is a notification from the ID list for Captive Portal Interaction.
> 
>     
> 
>     Document: draft-ietf-capport-architecture,
> 
>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris.com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris.com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D&reserved=0>
>     
> 
>     Change by Kyle Larose on 2018-06-30 05:04 PDT:
> 
>     
> 
>     New version available: *draft-ietf-capport-architecture-02.txt*
> 
>     
> 
>     Best regards,
> 
>     
> 
>             The Datatracker draft tracking service
> 
>             (for the IETF Secretariat)
> 
>     
> 
>     
> 
>  
>  
>

---

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Tue, 23 Oct 2018 18:23:54 +0000

Hi Tommy,
Thanks for your clarifications.
For 3) below.
In the example it would great if you explicitly either mark it as HTTPS request or add a phrase like over a TLS connection as shown below:

3.3.  Example Exchange over a TLS connection
   To request the Captive Portal JSON content, a host sends an HTTPS GET
   request:

Thanks,
Subash

From: <[email-masked]> on behalf of Tommy Pauly <[email-masked]>
Date: Monday, October 22, 2018 at 10:50 AM
To: "Tirupachur Comerica, Subash" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Kyle Larose <[email-masked]>
Subject: Re: Comments/Queries on draft-ietf-capport-api

Hi Subash,

2. Enforcement is referring to section 2.4 of the architecture document: https://tools.ietf.org/html/draft-ietf-capport-architecture-02#section-2.4<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-architecture-02%23section-2.4&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=rkqWfNTHnxHPc6w0kA6YxdUrxJypW8GqrabIkNGdJRg%3D&reserved=0>

Thanks,
Tommy

On Jul 16, 2018, at 4:09 PM, Tirupachur Comerica, Subash <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tommy/Darshak,
Greetings!

Thanks,
Subash

From: Kyle Larose <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 6, 2018 at 10:48 AM
To: "Tirupachur Comerica, Subash" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments/Queries on draft-ietf-capport-architecture

On 6 July 2018 at 13:43, Tirupachur Comerica, Subash <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kyle,

Thanks,
Subash

From: Kyle Larose <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 6, 2018 at 4:46 AM
To: "Tirupachur Comerica, Subash" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Subash,

On 5 July 2018 at 19:54, Tirupachur Comerica, Subash <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kyle,
Thanks for your response.
BTW, do you know if this is the right alias that gets archived? Otherwise can you please include the right alias?

"

Thanks,
Subash

From: Kyle Larose <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 3, 2018 at 5:51 PM
To: "Tirupachur Comerica, Subash" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments/Queries on draft-ietf-capport-architecture

On 2 July 2018 at 02:40, Tirupachur Comerica, Subash <[email-masked]<mailto:[email-masked]>> wrote:

Dear Authors,

I)

II)

We actually discussed this at IETF 101 if I remember correctly. The idea is that the client indicates in its http request accept header (https://tools.ietf.org/html/rfc2616#section-14.1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2616%23section-14.1&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=44wwlbgHcfUIJYVWiPNX648ksPLIdSslDIGb439yuzI%3D&reserved=0>) what type of content the client expects. A legacy client would likely request text, and they certainly would not request json. Thus, by serving up a standard html page for the text/html case, we maintain backwards compatibility. On the other hand, for modern clients, which will request application/json, we can serve up the API.

1. The most recent API doc (https://tools.ietf.org/html/draft-ietf-capport-api-01<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-api-01&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=7WSIOnfyQhEk18xLwmWWqe1LIvlvvKXpwHvVuT0BZBU%3D&reserved=0>) uses application/json-capport, so at the very least we need to update this\
2. I don't see anything about accepting text to fall back to html in the api doc.

III) Minor typos here:

   other.

   making the request.

*sigh*

       signals.

Thanks,

On 6/30/18, 5:04 AM, "IETF Secretariat" <[email-masked]<mailto:[email-masked]>> wrote:

    Hello,

    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris.com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=P4N%2BUD5pmzQQImEOkEB6qfVxkkdnjCWxyERpzwkSIEk%3D&reserved=0>

    Best regards,

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Oct 2018 17:34:35 -0700

Hi Subash,

Okay, I think it would be a preferable clarification to specify that the exchange occurs over a TLS connection, since the GET is not fundamentally different.

Thanks,
Tommy

> On Oct 23, 2018, at 11:23 AM, Tirupachur Comerica, Subash <[email-masked]> wrote:
> 
> Hi Tommy,
> 2. Enforcement is referring to section 2.4 of the architecture document: https://tools.ietf.org/html/draft-ietf-capport-architecture-02#section-2.4 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-architecture-02%23section-2.4&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=rkqWfNTHnxHPc6w0kA6YxdUrxJypW8GqrabIkNGdJRg%3D&reserved=0>
>  
> On Jul 16, 2018, at 4:09 PM, Tirupachur Comerica, Subash <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Tommy/Darshak,
> Greetings!
>  
> We actually discussed this at IETF 101 if I remember correctly. The idea is that the client indicates in its http request accept header (https://tools.ietf.org/html/rfc2616#section-14.1 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2616%23section-14.1&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=44wwlbgHcfUIJYVWiPNX648ksPLIdSslDIGb439yuzI%3D&reserved=0>) what type of content the client expects. A legacy client would likely request text, and they certainly would not request json. Thus, by serving up a standard html page for the text/html case, we maintain backwards compatibility. On the other hand, for modern clients, which will request application/json, we can serve up the API.
>  
> 1. The most recent API doc (https://tools.ietf.org/html/draft-ietf-capport-api-01 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-api-01&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=7WSIOnfyQhEk18xLwmWWqe1LIvlvvKXpwHvVuT0BZBU%3D&reserved=0>) uses application/json-capport, so at the very least we need to update this\
>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris.com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C164760f38bef427ded9008d63846f204%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=P4N%2BUD5pmzQQImEOkEB6qfVxkkdnjCWxyERpzwkSIEk%3D&reserved=0>
>     
>

---

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Wed, 24 Oct 2018 03:05:55 +0000

Hi Tommy,
Sounds good, thank you.

Thanks,
Subash

Date: Tuesday, October 23, 2018 at 5:34 PM

Hi Subash,

Thanks,
Tommy

On Oct 23, 2018, at 11:23 AM, Tirupachur Comerica, Subash <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tommy,

Thanks,
Subash

From: <[email-masked]<mailto:[email-masked]>> on behalf of Tommy Pauly <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 22, 2018 at 10:50 AM
To: "Tirupachur Comerica, Subash" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kyle Larose <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments/Queries on draft-ietf-capport-api

Hi Subash,

2. Enforcement is referring to section 2.4 of the architecture document: https://tools.ietf.org/html/draft-ietf-capport-architecture-02#section-2.4<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-architecture-02%23section-2.4&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C28aa5aa318a14ca4f0c108d639487de1%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=kl6C7eMBrNbzXV6Bol%2Fxf3KcmcXBNlP1RBlKrPpRHjo%3D&reserved=0>

Thanks,
Tommy

Hi Tommy/Darshak,
Greetings!

Thanks,
Subash

Thanks,
Subash

Hi Subash,

"

Thanks,
Subash

Dear Authors,

I)

II)

We actually discussed this at IETF 101 if I remember correctly. The idea is that the client indicates in its http request accept header (https://tools.ietf.org/html/rfc2616#section-14.1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2616%23section-14.1&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C28aa5aa318a14ca4f0c108d639487de1%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=rcXkgJ7uS266CehXcmctujK01oHrt2784Eeqh36hN34%3D&reserved=0>) what type of content the client expects. A legacy client would likely request text, and they certainly would not request json. Thus, by serving up a standard html page for the text/html case, we maintain backwards compatibility. On the other hand, for modern clients, which will request application/json, we can serve up the API.

1. The most recent API doc (https://tools.ietf.org/html/draft-ietf-capport-api-01<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-api-01&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C28aa5aa318a14ca4f0c108d639487de1%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=kg1zk4L7FRDglQXgf%2Brh38si2JUa0CE%2BlY%2B9YdT3RtU%3D&reserved=0>) uses application/json-capport, so at the very least we need to update this\
2. I don't see anything about accepting text to fall back to html in the api doc.

III) Minor typos here:

   other.

   making the request.

*sigh*

       signals.

Thanks,

    Hello,

    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris.com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7C28aa5aa318a14ca4f0c108d639487de1%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=LQ68vLeILNna6nGtuJf8PpOdb1JF5czwS6ozEZ7tR6A%3D&reserved=0>

    Best regards,