SPEERMINT WG Session IETF77, Anaheim ==================================== Jason Livingood and Daryl Malas open the meeting. Agenda bashing -------------- Jason talks about the Agenda, no further additions. Working group document status ----------------------------- Daryl lists the open documents of the WG with the respective status. Architecture Document --------------------- Daryl is not the author. Worked comments into the document - Daryl explains the diagram from the -10 version. The "ENUM" and "FQDN" boxes didn't exist. John Elwell: LUF is internal or external? Indirect is also not covered in that diagram. Daryl: We would have a lot of diagrams, we tried to stick with one. this is meant to be a functional diagram. John: Got confused what was functional and was physical Daryl: We need to clarify that this is functional David Schwartz: For the "LRF", either remove "DNS", or add "Other" as the protocol Jon Peterson: Put "example" under the diagram Daryl: Let's hum. If we add "example" to the figure, would that be ok? Result: no one opposed. Relationship between functional elements: Jon Peterson: Does the SF really perform those "functions"? Conclusion: "SF" should be changed to "SBE" in "A SF can perform LUF and LRF functions". "communications" part ok? If that change applied, consensus? Hum gives concensus. LRF-to-LRF? Daryl reads through the text. People are slightly confused. Daryl: LRF gives you the next hop, not the target. David: a routing function can return multiple hops Jon: Take out that section and move it to the routing table section. Daryl: good solution, yes. Daryl presents additional comments. Have we the relationships inconsistensies solved? John Elwell: not had the time to look at all of it, will send text to Daryl. 2119 language will be removed. Procedure of overwriting request header will be clarified. Hadriel: Overwriting is ok when it is re-targeting. Daryl: Will check that. Next Steps: Daryl: We might have lost touch with what we want to achieve. Lots of valuable things, but has been so long aronud that we need to wrap up. Jon: Document that clearly specifies the Architecture is definitely useful - get this done! Alex: DRINKS is based on this - please finish it to prevent confusion. ??: Needed by implementers also! Daryl: Who get's that done? Adam: nominate Hadriel? Daryl: We have got lots of valueable comments - let's do one more revision and then another WG last call Adam will do a -11 revision. John: Yes, we need another revision, then review by 3-4 reviewers, then WG LC. Jason: One of the *several* volunteers, yes. Alex Mayrhofer, John Elwell, David Schwartz, Jon Peterson, Micheal Miller will review. SIP Interconnect Guidelines --------------------------- David presenting. Responsible Entity slide John Elwell: Don't ignore that some SIP entities could be "upstream". Extension Negotiation slide - proposed change. David Schwartz: You may have to fix things that somebody broke - want to leave this in as MAY. Jon: Disabling extensions is different from protocol cleanup - text is good - not enough, but will have to do. Standards bodies included in Review slide Daryl: this addresses comments received that we should looks at other groups. SIP Interconnect guidelines slide lists documents looked at: i3, GSMA, 3GPP IMS, david schwartz: Found lot of value in the IMS Roaming text - thinks that we might miss the mobility aspect? Comment from Otmar whether anybody understands the GSMA concept under certain circumstances? Adam: Rhetorical questions that cannot be answered here? Conclusion of Comparison slides Jon: might be useful to keep that information around, for example for implementors. SPEERMINT Security Threats -------------------------- Jürgen Quittek on behalf of the Authors. Requirements vs. Solution slide Jon Peterson: Those Requirements are bad Jürgen: Requirements come from a different document Jon: Req #15: DNS does not have mutual authentication slide on Recent Changes (2) Slide on Recent Changes (1) John Elwell: inconsistency - lookup functions vs. signaling? David Schwartz: Document is lacking context - another point for getting architecture done. JFM: We know that requirement #15 cannot be fulfilled by DNS Jon: We shouldn't change the requirements at this point.. JFM: one revision is coming up - this is not changing... Alex: removing "mutual" would allow to use DNS Daryl: we shouldn't change requirements at this point JFM: It would be good to get out recommendations on what we should do to address the requirements New work -------- Daryl opens discussion about new work, for example the "egress routes" draft. comment from DISPATCH received that it might fit into SPEERMINT. Adam: Only *if* the information about egress is affected by information from *another* admin domain. *Within* a local domain is not in scope of SPEERMINT. Jon: Thinks this is within scope Richard Shockey: Agrees. Whether the information is from internal or external does not matter Adam: Disagrees: How i egress is completely a matter of local policy. Hadriel: Agress with Adam. SPEERMINT is about *inter*, not *intra* communication David: Thinks that this is a SPEERMINT topic Hadriel: this is part of the LRF. Should probably go to DRINKS? Adam: If you think this is SPEERMINT, why didn't you bring it to SPEERMINT? Mary Barnes: Followed the proper DISPATCH process. David: We could use LRF internally as well, we haven't figure that out yet. Daryl: What about dynamically exchanging routes? Alex: If DRINKS shall develop dynamic routing, then DRINKS is in the wrong area JFM: Does not matter where it belongs, but if there's interest, we should do it. Hadriel: Routes are dynamically exchanged, but back in Dublin we found out that neither Routing Area nor DRINKS would do it.