Alper, I don't have any problem with this, I just want to make sure that the IESG has seen and agrees with (i.e., discusses) this line of reasoning.
Thanks, --David > -----Original Message----- > From: Alper Yegin [mailto:[EMAIL PROTECTED] > Sent: Monday, September 17, 2007 3:53 AM > To: Black, David; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Jari > Arkko'; 'Romascanu, Dan (Dan)' > Subject: RE: Gen-ART review of draft-ietf-pana-framework-10.txt > > Hi David, > > Thank you again for the re-review. > > Dan Romascanu had flagged the "MUST implement" reference to > draft-ietf-pana-snmp I-D (a dead draft). In consultation with > Dan and Mark > Townsley, we agreed to remove that requirement. > > Just to recap how we ended up removing that requirement (from > two of my > e-mails): > > "The WG was originally scoped to work only on the PaC-to-PAA protocol > (PANA). Later the WG was asked by our previous AD to also > define at least > one protocol for the PAA-to-EP leg. We ended up embarking on > that work to > define a complete picture. > > Irrespective of the EAP peer (e.g., PaC) to authenticator (e.g., PAA) > protocol (e.g., PANA, PKMv2, IEEE 802.1X, HRPD), there is need for an > authenticator to enforcement point protocol when the two are > separated. > Today there are numerous protocols used for that (e.g., R6 in > WiMAX, CAPWAP > in WiFi, Rp in 3GPP2, and IETF's upcoming ANCP in DSL). Defining an > architecture-neutral protocol is a good task, but I'd say > it's better scoped > as a work item for a separate WG. > > For that reason, I'm leaning towards putting that work aside > for PANA WG. If > and when IETF decides to tackle generic authenticator to > enforcement point > protocol, draft-ietf-pana-snmp can be a useful starting point." > > And > > "According to our framework, as illustrated [Fig 1. in fwk], > PANA is part of > a larger picture that includes other protocols running between various > entities. > > While the core protocol work of PANA WG is running between > PaC and PAA, we > are also showing protocols between PAA-to-AS, PAA-to-EP, and > PaC-to-EP. > > The PaC-to-EP protocol is very much access technology > specific. E.g., PKMv2 > in WiMAX, 802.1X 4-way handshake in WiFi, etc. We list them > informatively. > > The PAA-to-EP protocol is also architecture specific. WiMAX > uses R6, some > WiFis uses CAPWAP, some ADSL would be using ANCP, etc. > > I think what we can do is, like we did for the PaC-to-EP > protocols, we can > informatively list the protocols (excluding SNMP) that are > used for the > PAA-to-EP leg." > > > > > Alper > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 17, 2007 4:26 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > > Subject: Gen-ART review of draft-ietf-pana-framework-10.txt > > > > 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). > > > > Please wait for direction from your document shepherd > > or AD before posting a new version of the draft. > > > > Document: draft-ietf-pana-framework-10.txt > > Reviewer: David L. Black > > Review Date: September , 2007 > > IETF Telechat Date: September 20, 2007 > > > > Summary: > > > > This draft is on the right track, but has open issues, described > > in the review. > > > > Comments: > > > > The items identified in the Gen-ART review of the -08 version > > of this draft have been addressed in the -09 version. They > > are still ok in the -10 version. > > > > The one significant change I noticed between -09 and -10 is > > removal of the "MUST implement" requirement for SNMP between > > the PAA and EP when these two entities are separated. This > > requirement has not been replaced. > > > > Whether the should be replaced is the one and only "open issue" > > in this review. I'm not sure whether the requirement needs to > > be replaced, but I am sure that the IESG should discuss whether > > it ought to be replaced, and if so by a requirement for what > > protocol, ANCP? I would be comfortable with a conclusion that > > not having requirement is appropriate, but want to ensure that > > this is done as a conscious decision and not by default. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
