PAWS working group meeting - Atlanta (IETF85) Thursday - November 8th @ 9am ========================================= Administrivia (5 min) Blue sheets, minutes taker, jabber Note Well Agenda bashing WG doc status (20 min) PS req/use cases was sent to IESG in August, Pete came back a few weeks ago with substantial, mostly editorial comments. Identified overlaps in the use cases, places where language needs to be adjusted. No feedback on the list yet except from Peter Stanforth and Nancy Bravin. Pete Resnick: given lateness, didn't expect immediate discussion, however, reason for AD review is to get questions out of the way before submission to IETF last call and IESG review. I need ammunition to defend the document before the IESG. Need discussion in the WG about the bigger picture, rearrangement, and other editorial issues. Make sure that you agree it is strictly editorial and willing to fix, then I can bring it before the IESG. How many people read through the comments? About 1/2 dozen people. If people want to talk about those now, great, if you want to defer them to the mailing list, fine, understand we have a document editor issue. BrianRosen: has been list discussion on the subject of use cases. . The issue is that the participants (in this case experts) believe that differentiating the cases has some value, makes a difference because regulators have chosen that they make a difference. PeteR: For IETF purposes, what I need to bring to the IESG, what's important is the architectural and protocol differences between the use cases. It may be that any particular regulator separated out the hotspot use case from the WAN in a rural environment, but in the doc now they are almost identical architectural/protocol wise, although Gabor pointed out there may be one difference. Important thing is not that it is a hotspot or rural network, but that you identify the differences very clearly so that I can go to the IESG. Right now I couldn't find the difference between the two. Stylistically, question of is it good to have them in one sections or two subsections or two different sections, I'm agnostic, one section might be easier to read, but whatever. Important thing is two use cases for architectural/protocol impact have to be clearly differentiated, right now they're not. Gabor: 6 use cases in the document, one of which is the mobile use case, so the two that Pete mentioned plus the mobile use case could be combined. We need to identify the procedure. PeteR: collapsing use cases doesn't mean we should make them non-differentiated, ignore differences, actually the opposite: highlight differences from an engineering perspective, ignore irrelevant stuff. TonyMancuso: could volunteer to go through the doc, so that you get what you need here, engineering needs, get rid of redundancy, volunteer to do that. Gabor: would have been my second issue. Current editor has left, need someone to take care of the document? Tony: yes, will put it on the list and make sure that everyone follows my approach. PeteR: because comments were so late, I'm happy not to spend more time on it. Either way if people have comments or not is fine. Gabor: comments are mostly editorial, no comments on requirements which were derived from the use cases, right? PeteR: had a couple of comments on particular requirements, why is this one there, is there one missing. Requirements you ended up with were relatively solid. A lot of the requirements said "regulatory requirement" as a catch-all phrase; need to flesh out the engineering requirement behind the regulatory requirement. If that means use a data structure specified outside the protocol, that's a wording difference, just want to make sure there's no engineering guidance missing. Gabor: status of solution document. We had two solutions, agreed last time to merge them into one document, new editor merged the non-controversial parts. We agreed on the list to define INIT messages, JSON encoding, no shared secret based authentication. Chair asked if there are objections against adopting the document as a working group document, received no objections, assume WG is ready to adopt. No objections? Ok, ask the editor to submit the document as a WG document. PeteR: make sure there is a way to put in the replaced-by information. VinceChen: submit to the list, in the process of submitting there is a replaced-by thing? BrianRosen: when you submit it, if it doesn't happen automatically, there's a tool I can use to make it replace. PeteM: do we need to replace the other two input documents as well? BrianR: generally no we don't need to do that. http://www.ietf.org/id/draft-vchen-paws-protocol-00.txt (Vince, 60min) Gabor: Vince, you have some open issues with the document? Vince: First highlight what happened during the merge, what's in the document, then I'll go through some of the open issues that haven't been decided. Clarified what were regulator-specific, optional, mandatory parts. Overview of the messages. Database discovery, available spectrum query that are mandatory. Still open as to whether we are going to discuss discovery in this particular document. Other messages are optional. For example, Initialization is a setup point, extension point to add things by future regulators. Device registration is regulator specific, so it's optional. Device validation is also regulator specific. Spectrum-use notification is also regulator specific (e.g., Ofcom requires a feedback mechanism). PeteR: is there a reason that registration and validation are just not simply optional steps of initialization? Why are they called out separately as steps, they look like things you would do as part of initialization? Vince: registration is for a fixed device. Validation is for slave devices, master device is validating them with the database. PeteR: ok, let's separate out the two cases. When the Master is doing registration, sounds like initialization of the master. What's the difference? Vince: depending on the requirements, there is a case where the FCC is allowing a pre-registration of the device, so that subsequent communication doesn't have to come through device registration. JohnMalyar: initialization function in the previous document is used when device establishes communication with the database, understand the relationship with that regulator. Registration is a one-time event in the life of the device, particular to one regulator and class of device. In some regulatory environments, it only happens once, doesn't have to happen unless it moves. PeteR: ok, that was helpful. So it can happen a long time before the query, right? Vince: correct. PeteR: Now validation. This is essentially registration for the slaves? Vince: not registration, not persistent, only are they allowed to make use of this. PeteR: so each time a slave comes on it's going to have to re-validate? Vince: yes. JohnMalyar: registration contains owner, how to contact that owner, validation is only to validate the ID. Registration is a one-time event. Vince: current draft also allows the registration information to be specified during each query. BrianR: kind of forward looking because we don't know what the next regulator might do. PeteR: makes sense if device registration is asynchronous, then piggyback on query or send it whenever makes perfect sense, will re-read the protocol and see if it's connected appropriately. BrianR: your confusion means we need to spend more time explaining why we're doing this, so please read it in that light. PeteR: in most of my other WGs, I know sort of the direction they're taking, but because you are coming in from regulatory/IEEE angle, I'm going to be proactive as we develop this document. I hope to be asking these questions all along. Vince: Initialization function Exchanging Capabilities Device would provide the database information about itself (identifier, location) plus additional optional regulatory or database-specific information. Response contains some ruleset parameters, in addition to allowing the database to provide regulator-specific responses. TecoBoot: Why Ofcom optional? I would say FCC is optional? Vince: ok, I'm pointing out an example. What I meant is that as far as the protocol message is concerned, there is a common piece for all regulators, and then there are regulatory specific section. TecoBoot: cannot be that FCC is mandatory, others optional PeteR: violent agreement BrianR: it will be that we have a set of optional parameters, and then regulators will define which of the parameters you need. Gabor: want to point out that what this slide says is that request can have parameters, identify the device, for OfCom case, identify this is the technology I intend to use in this spectrum. Vince: what I hope to define here is that the device could send everything it knows about itself pertinent to all regulators in this message. Database can ignore things it doesn't understand. It could provide everything. UK database can extract this part of it. BrianR: Can you consider making this protocol exchange a little bit more complicated? Send common information first, then get a message back which says what else you need to send. Tells device what domain it's in and what information it needs. If I build a device which is world-specific, then I have to send everything I need for every regulator in the first message. Vince: adds an extra message BrianR: yes but many devices will be useful with many regulators Vince: want to make sure one database could be used for many regulators BrianR: sure, database could tell you which domain you're in and what you need to send. Seems like it's a better tradeoff to have more messages and fewer pieces of information to send. TecoBoot: Brian was adding something like a profile so you can specify what information must be in the profile, and then comply with those, it is easier to get devices certified. Protocol will have all kinds of optional stuff. Then you can comply with all the region-specific things. Vince: would like that, want to leave open the possibility of extending that. Teco: but before the product is put out, the stuff is known. Vince: FCC is already out there certifying devices, we don't know what those things will be. Teco: those things will change. Vince: so have these things be a profile Teco: is the protocol that flexible, or is there an abstraction layer that says what you must send as part of the profile. Vince: intent was there is a must-have section in the request then that can be extended. Teco: maybe you can say some protocol elements are always mandatory, some are optional. So each couple of years regulators will change the rules, then we have a problem in 10 years or so, many levels of certification and databases/ master devices should comply, it is more difficult to get right. PeteR: drill down: "required for all implementations" are the common parameters, you are talking about optional parameters per the protocol, but post Init exchange they may be required by the database. Then of those, there are optional ones the database will accept. So there's optional for protocol, then optional for particular instantiation of a regulator/database. The ones you have listed as optional, database needs to be able to say which ones are mandatory which ones are optional. JohnMalyar: idea of having initialization in two phases might be ok, want device to be an abstraction of what domain it's in. Discovery might provide some of that, but we don't quite know how it's going to work. Maybe we need a separate mechanism. Henning: another spin on parameter abstraction. Anything that requires an explicit profile is probably bad, to the extent possible you want devices to work worldwide and as regulations evolve and with no manual configuration. Two cases when things change: (1) information that the device knows, didn't need to provide before now it does. In that case, there should be a protocol the database just asks for the information it needs, it can happen automatically. Just need a protocol that is sufficiently flexible. (2) a new parameter is introduced that didn't exist in the protocol or the device didn't know about before. All the profiling in the world isn't going to fix that. Either software has to change, because it's a completely new thing, or the operator of the base station has to provide/measure additional information that needs to be entered. Vince: yes. Henning: vast majority of cases handled without profiling, profiles multiply, if a new profile shows up, you are perfectly capable of providing the information you just didn't know the profile code. Seems like a bad failure scenario. What we want is something to the extent possible the database can query for information from the participant. Three cases: (1) device has information (easy) (2) device doesn't know it, but flags an error and operator enters information (3) new mandatory parameter shows up that requires software upgrade. To the extent possible, (1) and (2) should be the case. Only in case (3) does the protocol break. Vince: don't know how the intermediate would work, if the device was able to respond to a query, it would already have to have a list of named parameters that it knows about. BrianR: could easily build a device that can configure a new parameter by typing in the name/value, not requiring software upgrade. Henning: right, or if there is a parameter that I already know about, there's no good reason not to tell the database. What you said is what we do today for MIBs, etc, you can install a new parameter without a new version of SNMP Vince: still requires manual BrianR: manual but not software upgrade Henning: want to minimize software upgrades, but we do this all the time for configuring operating systems (Windows Registry, etc) Vince: can encode that by saying if the set of parameters has been configured it can be sent over as a mandatory part Henning: database can indicate that it needs parameters A, B, C; device can supply A, B fine, C unknown it flags an error, operator can go fix it by looking up C in the manual, regulatory rules, etc. This only works if the protocol as part of it's mechanism, the database asks for a new parameter by name (not profile ID). TecoBoot: heard it's quite easy to add a profile as a new info element, but profiles can have a very different purpose, that is, getting certification. We are not just talking about protocol flexibility, we are also talking about getting certification. Products can evlolve. There is IMO a requirement for the protocol for how to deal with this. In the information exchange, there must be type of device, what parameters you can provide to me, need to handle old and new devices. Vince: what do you think about: if a device needs to be certified with new requirements, and it already provides that to the database, the database needs to know what generation of device that is, doesn't ask for particular fields Teco: maybe there are ways to send a profile, don't mix them together. Gabor: please summarize, you need to move on Teco: will take it to the list PeteR: not necessary to have that exchange; device can send everything it knows, database can then send a response code that says I won't talk to you because you don't have the right information. May end up with too much information, need to define at what step this makes sense. Could be during database discovery, at request/initialization time. DaveHallas: lot of good conversation, was the intent of the presentation to give us just a status of how the merge happened. Vince: this part, how the merge happened Gabor: we certainly need to move forward. Brian was saying we need not send everything to the database, may need to be regulatory domain specific. Database discovery may allow regulatory domain discovery. BrianR: that's the profile idea. Some people don't want to get stuck in profiles, want to have the database tell me "I need this, this, and this" device can then respond with that. Tradeoff of an extra protocol exchange is a good tradeoff. Henning: just know from experience that naming profiles, versioning gets unnecessarily complicated. If you want to certify, you can do that without profile names. WarrenKumari: can see the desire for profiles, but profile doesn't need to be in the protocol. Vince 3 basic open issues. 1st is on encoding, we decided on JSON, here are some ideas that are not in the document. As long as we are going down the path of JSON, do we want to consider JSON-RPC? Request/response JSON objects Natural fit for PAWS protocol Example Current doc has RequestMessage and ResponseMessage, we could replace that with JSON-RPC. JohnMalyar: is this understanding of what the text string portion may be, or is it a different methodology? May be HTTPS POST with JSON string? Vince: yes JM: still based on current architecture description? Is it just a more formal wrapper? Vince: just an existing wrapper. Seems ok? Didn't define any errors. Proposal is to keep PAWS and HTTP layers separate. HTTP would always be 200 OK, PeteM: still sometimes good reason to send an HTTP error Gabor: any objections? Put it to the list and we can put it in the next version of the document. Encoding of regulatory requirements, what's mandatory what's optional. Do the specifics for each regulator belong in the body of the document or in the appendix. And is it normative or informative? Secondarily, this is a possible encoding with 2-letter country code. PeteR: question: should this stuff go in a registry of some sort, outside of the document? If it did, would it answer the question you just asked? Vince: probably, I don't know what that registry would be. Don't know the mechanism. BrianR: while there will certainly be cases where a specific regulator defines a specific value will happen, it will be rare. The notion of the FCC-ID is a counterexample. So your idea is the right idea: there should be a registry of items that the database wants, then say, these items are required in these circumstances. Registry is just the list of items that could be asked for. Could be mandatory in some environment, optional in some environment. Make it a registry, don't make it specify to a regulator. E.g., FCC-ID is a data type but is not specific to FCC section. PeteR: IANA registrys can be lightweight, anybody can come and register. Doesn't have to be heavy weight.. Country-specific: registry doesn't need to state which things are required/optional for each domain, we could put helpful information in registry. To decide which is mandatory/optional we have to deal with the previous question. Vince: do we have to define what the registry looks like PeteR: yes you need an IANA section of the document. Vince: would appreciate help Henning: another reason not to tie this to countries, smaller countries often re-use framework of another country. Some other country might use the FCC-ID because they don't have a market of a needed size. Any parameters should not be country-specific. Leads to unnecessary failures. Vince: different regulators may have device types, defined differently for different regulators? Are those two data types? Henning: if it is a device type which is specific to a regulator, you can tag it that way (e.g., FCC-ID) if there is a specific way of measureing things, want to make that clear with two separate data element names. What you do want is a sub-case for optimization only, enumeration where certain values don't appear in certain countries, could be subset or superset of a registry, if you use a value that doesn't apply to a given country, you get an error. That's what the registry process will establish. Those you need to differentiate. PeteM: don't want our document to define which parameters are required in which regulatory domains. JohnMalyar: in case of identifying the device-ID, might be valuable if we have a device-ID and a serial number might be good to have. Encoding: JSON schema Using the protocol that we agreed we probably won't be using. Need to fit this into JSON-RPC methods. Encoding: GeoLocation Lat/long and height of antenna, what is the data item that should be considered for protection. In a portable device, device and antenna are together. Could be cases where device is in a facility and antenna is separate. Intent is lat/long of antenna, not device, right? JohnMalyar: why are we trying to determine the intent of the regulator, rather than just defining an envelope? Is this because we are trying to help the device? Why do we need to interpret the intent rather than providing a vehicle? Vince: device knows what it knows, want to be unambiguous. Henning: shouldn't see this as just we do protocol development, regulator pays no attention. What we want is a feedback loop. There are people in regulatory agencies that are engineers, they read standards docs, if a doc says you should specify certain parameters, regulators are likely to reference the doc. We should specify the one that makes most likely engineering sense, then if we miss something, they will point it out. Wouldn't worry that this is a one-way transmission process between what happens in PAWS and what happens in regulatory agency. Regulator will refer to these elements. JohnMalyar: don't want to disagree that there is a symbiotic relationship between standards and regulators. Initial discussion on the list is "what is the height"? How are you defining height, not what element? Important not to impose a particular interpretation of that parameter, shouldn't constrain us from supporting any existing regulations. PeteR: Seems like a deferable question. If you have a registry, you can have an element returned that is lat/long and altitude of transmission point. If a regulator or anyone else wants to know device lat/long/altitude that could be a separate registerable parameter that I might need to get information for. Sounds like we could defer it until we start registering things and register those items that we think will be needed. Vince: there is a field called location. Should we have that field be a single triplet? Or are we separating device lat/long/altitude, plus another thing. PeteR: why is there a field called "location"? Vince: this whole thing is based on available spectrum at a location. PeteR: there are different kinds of locations, field should be "Lat/Long/Alt of Antenna". Someone may come along and say we need something else, call it something else. Vince: from a data model perspective would like to have some structure to it rather than a list of fields that could be unrelated somehow. BrianR: don't want to get too crazy here. Admit to the possibility of having antenna/device in different places, but we shouldn't need to worry about it. TecoBoot: can have set of requirements seems more difficult to request information from device, now it has to ask for this set or the other set. Discussion on the profile, we can just ask for the parameters. Now we have to ask HAMSL or HAAT. Makes me worried. Vince: because this is core of the protocol, should just be something that's provided database doesn't need to ask for it. A couple of reasonable ways. Installer could measure and input to the device. TecoBoot: requirement in the implementation "transmitted power with this parameter OR the other parameter". Makes it quite complex. Vince: going back to the registry point? Gabor: if we are going to have that possibility for the database to ask the device, "please give me these set of parameters" what is the database going to ask for? Vince: don't want the database to ask, just want to send it. ZhuLei: parameter is useful, want to specify antenna as 3-dimensions Henning: we already discussed, people can send everything they know or database can request stuff. I thought we agreed that if we have a registry, database can specify. Vince: previous discussion, we were focused on INIT message, now this is sent every time. PeteR: you're suggesting that whatever is in the registry, the protocol defines some locked-in parameters, we can figure out which one is the right one, lock it into the protocol, then we don't have to put it in the registry. Henning: ok, that's an optimization that shouldn't affect the basic mechanism. BrianR: generalizing, for both the INIT and protocol exchange, there is a set of information that is always required, stuff that is optional for protocol mandatory for regulator, other stuff optional for both. Henning: my point is that everything that isn't optional is explicitly requested. JohnMalyar: in agreement there is some part of the protocol that is fixed, knowing the location of the device is important, but how we label that third parameter, we need to be careful that either the installer or device can determine, we don't assume that it's one and only one value, ability to share with database is mandatory. Gabor: what we require is that in addition to the height you need to send the data value. PeteR: if this is in the protocol as a locked-down thing, we need to define the semantics of all the fields. We need to lock down a particular semantic, and make sure it is convertible for any device. Any device that knows its lat/long, might know its altitude, we can all come up with really goofy examples like an underground device, wire that goes up to some point above. Want geolocation locked down to either HAAGL or HAMSL. Vince: reasonable because that's what's actually measurable. PeteR: if it is a locked-in parameter, there should be only one, e.g., HAMSL and device should convert to that. PeteM: if it has different semantics, it should have a different name. Vince: so protocol should allow both HAGL and HAMSL, how do you want to encode that? WarrenKumari: device may have one or the other, PeteM: should label the data type. JohnMalyar: some devices are not required to even send height. We are overcomplicating that. If we are going to label each and every permutation we are overcomplicating. My understanding of all the different regulatory work that's being done, it's very limited the different types of heights. Vince: should we use location without height, ignore it completely? BrianR: use 6225, specifies location of base of the tower. If you have altitude, use that, then if you want separate height then you add that. WarrenKumari: when I first connect to the database I need to tell it where I am. After that, database knows what regulatory domain you're in and what other stuff. BrianR: in some domains need to send location in every query. WarrenKumari: there could be two sets of location. Gabor: do we want to have location in the registry? BrianR: 6225 location doesn't need to be in the registry. These other heights need to be in the registry. PeteR: there are devices that can't figure out their altitude, does 6225 allow me to say "I don't know?" BrianR: yes, WK: infinite uncertainty WarrenKumari: should be possible for database to say "tell me your altitude" BrianR: if you have the height as defined by 6225, send it as 6225. There can be other locations specified in other data items. BrianR: document must talk about this. Vince: In the Wei document there was a Batch Request mechanism. Address a mobile device that's traveling, may want to pre-ask for answers. If database supports a batch request, each response is computed independently. Gabor: instead of making N number of queries, you are making one query for N locations. Vince: to avoid overload, database is allowed to provide subset of responses and in any order. JohnMalyar: by the time you get there, data may not be valid. When you get to that location, you're going to have to query anyway. Vince: there is language in the FCC CFR that suggests this JM: FCC still requires you to re-query at the new location. PeteR: if you satisfy R. D8, provide for areas, does batch request completely go away, or are there batch requests that get you something the area may not get you. Vince: area may be compute intensive Vince: agree with JM there is conflicting language in the FCC regs Teco: should be possibility to pre-allocate spectrum and not have to re-query when you're out there. Gabor: want to note that even though we're going to have this possibility, we are still not satisfying Req D.8. vince: D.8 says you must support a query inside an area. Could do that in one of two ways: (1) extend 6225 to add Radius to define a circle, and/or list of points to define a polygon. Or, (2) JSON encode RFC 5491 (only need circle and polygon shapes). Vince: we tried to do GML in the database interop spec. In the XML you load the whole schema, it's a pain. It became fairly complex, with a lot of interacting files. Do we have to do the whole JSON encoding or can we just do a part of it? BrianR: 6225 is the DHCP option. Going back to 5491 is the right thing to do. Putting another work group in the path of success, it is easier to do option 2. PeteR: it's going to come down to whether group thinks it's worth going to 5491, or whether we add one field radius, or a bounded list of points, that sounds relatively simple to do we don't have to go back to geopriv. BrianR: disagree. You are adding a shape. In geopriv shapes were an issue we have dealt with many times. You are asking 6225 be extended to support circle shapes. It's the wrong thing to do. Henning: support Brian. While it's easy to extend shapes, there are always specific things we don't want to reinvent. Simple things like polygons there are always funny questions that arise. Subset of option 2 seems much less likely to confuse. If it turns out you need something other than circle and polygon, there is a natural path. BrianR: if you have a sector antenna, you will want arc-band. Gabor: assuming option 2, do we have a way of dealing with JSON and the name spaces? PeteR: if we have agreed on JSON, there is work to do to encode 5491. For tiny devices, option 2 may be difficult. Would like to hear on the list whether option 2 is going to be reasonable for the folks that are going to be doing stuff. I do not want to see the chair shaking his head no that's not a possibility. BrianR: headshake was personal opinion. As chair, let's take this to the list. PeteR: also want to hear from the folks that are implementing this. Henning: given that JSON is preferred over XML in IETF these days, would imagine that 5491 JSON encoding would be recycled elsewhere, can be explicitly or implicitly sent to geopriv. Gabor: suggesting we should define encoding in separate document and use it here? Henning: should coordinate with geopriv, no personal opinion. Recognize this is a re-use and creation of value, so naming/other things should be done in a way that makes sense. Gabor: we could initiate dialog with geopriv on this. Vince: mechanics of this: 5491 and XML encodings is a nested set of things that you pull in. In JSON where those nested structures don't exist, are we defining by examples, ... ? BrianR: there is a particular expert I want to bring in. Martin Thompson. Richard Barnes may have already done it. Vince vCard encoding draft-bhat-vcarddav-json-00 provides JSON encoding of vCard. Only contact fields will be used. PeteR: weirds is also considering exactly the same thing. They haven't decided one way or the other yet. We may have plenty of workers to get this document done out the door. Gabor: sounds like a good idea. Database Discovery Does it belong here or not? Gabor: question is not whether it belongs or not, do we have a volunteer who will write a few paragraphs or generate a new I-D? Security: observations integrity/MitM attacks. On authentication, how extensive do we need to make that? Not really protecting the spectrum per se, malicious device can always operate without contacting the database. No current whitespace rules say you have to authenticate the device. PeteM: not about protecting spectrum, it's about the resources of the database and making sure it can get paid for providing services. Vince: may be out of scope BrianR: we have to get the document through the IETF, there is a security considerations, they won't let us whitewash this. We can say something simple. e.g., self-signed certificates are adequate for this reason. Vince: examples we come up with, it is really hard to guarantee device security throughout the whole ecosystem. YangCui: how secure we need for client authentication is possibly to be solved, depends on the cost and what security level you need. Depends on requirements for security. Gabor: is your question whether client auth should be in the document or not? Vince: do we need to go any deeper into specifying a mechanism given that there's some text in there already? Gabor: we need to specify some mechanism, IESG will expect it. Don't know the answer right now. Gabor: Thanks, Vince, We made some agreements, please submit a new version of the doc as a WG doc. time permitting: http://www.ietf.org/id/draft-wu-paws-secutity-00.txt (Yang, 20 min) YangCui: Security Considerations Motivation: focus on the security countermeasure for WG document. Try to do something that is potentially useful for document. There seems to be agreement that we need database authentication, but there is disagreement about client authentication. Current requirements say that client auth SHALL be supported, but is optional to deploy. We are proposing some possible solutions for that. Some other material on how the regulatory body may authorize the device to be used. Why present here? -00 version before Vancouver meeting, no time to present, lots of discussion on the mailing list and after the meeting. -01 version, simplify auth models, Gabor: in the merged document there is a client auth mechanism described, which was merged from your document? Are you proposing to add more details to what is described there? Yang: merged draft says client auth is not required because of some things. Gabor: client auth is there, do you think not enough details, what is the purpose of your document? Yang: that description may not be sufficient for PAWS. We can provide more details. Gabor: free to propose paragraphs to the list, then put it in the merged document. The limitations of TLS/topics I don't think they belong to this working group. If there are problems with TLS and limitations you should send to TLS working group. Yang: not out point to criticize TLS. Since WG has decided to use TLS, want to point out the limitations and how to deal with them in PAWS. This draft includes, but not restricted to: Channel binding physical attack to master device (secure module like TPM) Countermeasures should be considered if WG decides they are necessary Gabor: in the requirements, there is a security threats. Are you addressing those threats? Yang: yes, we are defining countermeasures Gabor: possibly what you could do is send to the list the paragraphs themselves because you didn't get any comments on the list. Yang: protocol document is trying to do something minimal to support security. Client authentication is listed as a MUST to support. Current WG document not willing to include security countermeasures as detailed description. Gabor: that's for WG to decide. Send your proposal to the list. If group decides they don't want it in, you want a separate document? Yang: possible to have a separate document if WG chairs and AD think it is necessary. BrianR: preference is to have fewer documents than more documents. PeteR: as a process point, the base document, the protocol document has a security considerations section. If you feel there are pieces missing, post those to the list. Current direction of the chairs is that we should put security protocol in the document. If you don't get support, make your case. Neither the chairs nor the AD is going to allow something in a separate document that the WG didn't want in the protocol document. WG has to agree on output of WG documents. PaulHoffman: would be disaster to have two documents. If we do know there is a second document coming, we will block. Gabor: can always reference from one to the other. Yang: one possible solution, authentication with RBWS Gabor: ok, last agenda item. We are done.