Hi, Dan, I understand your frustration. My comments are coming very late in the process and I don't have a lot of time invested in the draft as you and the other authors do. Still, I think it's important that the IESG consider the issue I've raised, as I think it goes to some fairly fundamental architectural questions. As Gonzalo mentioned in the other thread, this kind of issue was raised earlier in the working group discussion; however, I note that it doesn't appear in anywhere in the PROTO writeup.
Ultimately, it will be up to Russ and the rest of the IESG to determine whether to hold up the draft over this. My comments don't have any more weight than any other Last Call comments. -Pete Dan Petrie wrote: > Peter: > I would not want a router/NAT/firewall/SBC to enforce > application-specific policies either, but unfortunately they have > escaped into the wild and administrators are using them to do just > that. You are welcome to stay in your fantasy, but the rest of us > have to deal with them. We are struggling to make things work. > > Now you have a choice here of being constructive and making > suggestions on how to improve this and accomplish our goals or you > can create a barrier that wastes lots of peoples time. Tens of > thousands of hours have gone into the discussion of this draft to > make it better. This is not an exaggeration, this draft has been in > the works for nearly 10 years. Anyone can create a barrier. Its not > hard to do. Please make suggestions on how to improve it or kindly > step out of the way to let someone else suggest a way to > improvements. Idealization and wishful thinking is not going to make > these router/NAT/firewall/SBC go away (i.e. removing the > local-profile because you do not like the idea that we have to deal > with things we wish did not exist is not a solution). > > I hear help is needed to outlaw NATs in IPV6 > > Cheers, > Dan > > > > --- On Mon, 1/11/10, McCann Peter-A001034 <[email protected]> > wrote: > >> From: McCann Peter-A001034 <[email protected]> >> Subject: RE: Gen-ART review of draft-ietf-sipping-config-framework-16 >> To: "Dan Petrie" <[email protected]>, [email protected], >> [email protected] >> Cc: "Sumanth Channabasappa" <[email protected]>, "Robert Sparks" >> <[email protected]>, "Volker (Volker) Hilt" >> <[email protected]>, "Gonzalo Camarillo" >> <[email protected]> >> Date: Monday, January 11, 2010, 1:33 PM Hi, Dan, >> >> I wouldn't want the router/NAT/firewall/SBC to enforce >> application-specific policies. I think that is actually the root >> cause of the problem and that box needs to be made transparent. >> >> I read through the policy framework that you linked to, and I >> understand the motivation of some service providers to attempt to >> control attached endpoints. I happen to think it is misguided to >> attempt to do so. >> >> -Pete >> >> Dan Petrie wrote: >>> Hi Peter: >>> >>> I think that Gonzalo covered this, but here is my view on the >>> local-network profile. >>> >>> The whole point of the local-network profile is so that the SIP UA >>> can figure out how to make things work. Sure a >>> router/NAT/firewall/SBC can enforce policies, but that does not help >>> the UA make things work or figure out what is allowed or preferred. >>> How does it get out to the big I Internet? A SIP UA is not so >>> interesting if it can only make local calls. The point is to figure >>> out the recommended technology to traverse the NAT/firewall, what >>> media types and/or bandwidth is preferred in the local network. >>> >>> Basically session independent policy is dependent upon the >>> local-network profile >>> (http://www.ietf.org/id/draft-ietf-sip-session-policy-framework-06.txt). >>> I expect there is some good text rationale in some of the policy >>> discussion threads on the email list as well as in the policy draft >>> for this. There is also an old expired policy requirements draft >>> that may reiterate the rationale. >> >>> >>> Cheers, >>> Dan >>> >>> >>> --- On Tue, 12/22/09, McCann Peter-A001034 >>> <[email protected]> wrote: >>> >>>> From: McCann Peter-A001034 <[email protected]> >>>> Subject: Gen-ART review of >> draft-ietf-sipping-config-framework-16 >>>> To: [email protected], >>>> [email protected] >>>> Date: Tuesday, December 22, 2009, 5:30 PM I have been selected as >>>> the General Area Review Team (Gen-ART) reviewer for this draft (for >>>> background on Gen-ART, please see >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html >>>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ). >>>> >>>> Please resolve these comments along with any other Last Call >>>> comments you may receive. >>>> >>>> Document: draft-ietf-sipping-config-framework-16 >>>> Reviewer: Pete McCann >>>> Review Date: 2009-12-22 >>>> IETF LC End Date: 2009-12-24 >>>> IESG Telechat date: unknown >>>> >>>> Summary: One big issue to discuss >>>> >>>> Major issues: >>>> >>>> I don't understand why the local network needs to be involved in >>>> SIP provisioning. The end-to-end principle should dictate that >>>> SIP is an application that runs transparently over intervening >>>> networks. >>>> >>>> From Section 3.2: >>>> In such cases, local >>>> network providers may wish to provide local network information >>>> such as bandwidth constraints to the devices. >>>> Why should the bandwidth constraints applicable to SIP be any >>>> different from the bandwidth constraints applied to any other >>>> application? >>>> >>>> I suggest dropping the local-network profile type. >>>> >>>> Minor issues: >>>> >>>> Figure 5 is confusing: it shows user A obtaining service before >>>> user A's profile is downloaded. Similar for user B. Shouldn't the >>>> profile be downloaded to the kiosk before service is provided? >>>> >>>> Section 5.2.1: >>>> Additionally, the device MUST >>>> authenticate the PDS >>>> to ensure that it is obtaining sensitive profile data from a >>>> valid PDS, except in the bootstrapping >>>> scenario. >>>> Why not in the bootstrapping scenario? That seems to be the most >>>> critical operation. >>>> >>>> >>>> Nits/editorial comments: >>>> >>>> Section 5.1.4.2: >>>> it MUST be >>>> use >>>> SHOULD BE: >>>> it MUST use >>>> >>>> Section 9: >>>> The framework specified in this documents >>>> >>>> SHOULD BE: >>>> The framework specified in this document >>>> >>>> Section 9.1: >>>> in the absence TLS >>>> SHOULD BE: >>>> in the absence of TLS _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
