Re: [Last-Call] [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, May 12, 2020 at 8:10 AM Kyle Larose <kyle@xxxxxxxxxxxx> wrote:
Hi Bob,

Thanks for the quick feedback.

> I am curious why section 3.4 does not consider the MAC Address as a possible identifier?

Its omission doesn't mean that the MAC Address is not a valid
identifier. One should evaluate it using the criteria provided in 3.2
and 3.3. When I wrote the skeleton of this section, I left the MAC
Address out more to keep the section short than anything, though I did
consider adding it.

Bob, do you think the MAC address needs to be considered in this
section for completeness?


I won't argue too much if you decide to leave it out, but it seems like the most obvious identifier, and is used by many things, so it would be good to list its pros and cons.
 


How does the capport wg feel as a whole about this question?


I am also wondering the same thing.   
 

Thanks,

Kyle

On Mon, 11 May 2020 at 13:36, Bob Harold <rharolde@xxxxxxxxx> wrote:
>
> I am curious why section 3.4 does not consider the MAC Address as a possible identifier?
>
> --
> Bob Harold
>
>
> On Mon, May 11, 2020 at 12:56 PM The IESG <iesg-secretary@xxxxxxxx> wrote:
>>
>>
>> The IESG has received a request from the Captive Portal Interaction WG
>> (capport) to consider the following document: - 'CAPPORT Architecture'
>>   <draft-ietf-capport-architecture-08.txt> as Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> last-call@xxxxxxxx mailing lists by 2020-05-25. Exceptionally, comments may
>> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
>> of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This document describes a 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.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
>>
>>
>>
>> No IPR declarations have been submitted directly on this I-D.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux