Re: [Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06
Hi Spencer, On Dec 29, 2008, at 6:13 PM, Spencer Dawkins wrote: Hi, Jouni, Thanks for your quick response - I'm OK with most of your proposed changes. I should emphasize that my comments here are Last Call comments that you (and the document shepherd, and the AD) can decide to ignore - I'm just telling you what I'm seeing when I read the text. Just to finish up: Some of the potential use-cases were listed earlier in this section. The general aim is better manageability of services and service provisioning from both operators and service providers point of view. However, it should be understood that there are potential deployment possibilities where selecting a certain service may restrict simultaneous access to other services from an user point of view. For example, services may be located in different administrative domains or external customer networks that practice excessive filtering of inbound and outbound traffic. Spencer: I wasn't clear on who this understanding is directed to - it almost reads like you're warning users that bad things might happen if you use a specific service, but surely the user specifies the service because an operator requires this? We had this discussion earlier on RFC5149.. and concerns were raised whether the Service Selection is a potential tool for enabling walled gardens etc. Thus this note here was added to emphasize that point. I understand your point from your explanation, but can't get that understanding from the draft text. If you said s/from a user point of view/from a user point of view (for example, a walled garden)/ that would be as clear as your explanation. Ok. Thanks. Will add this. 3. Service Selection Extension At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. It SHOULD be included at least in Spencer: seems to be missing a qualifier: When a non-default service is selected, the Service Selection extension SHOULD be included ...? Spencer: If this is qualified, could the SHOULD be a MUST? Hmm.. right. New text would be: At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. The Service Selection extension MUST be placed in the Registration Request message as follows: Spencer: If it remains as SHOULD, what happens if the Service Selection extension is not included in the initial binding registration, but is included in subsequent binding registrations? The first RRQ would be treated as the selection of the default service. The subsequent RRQs with the service selection would cause reauthorization evaluation of the requested service. If the newly requested service conflicts with the default service from the HA point of view, then an appropriate error is returned and the binding is dropped. I'm still confused by When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. My understanding from your explanation is that, by definition, if you don't include the Service Selection extension, you aren't selecting a non-default service until you DO send an RRQ that includes the Service Selection extension - right? If I'm tracking you, you're talking about two cases at the same time - what happens if you DO include the extension in the first RRQ, and what happens if you DON'T include the extension in the first RRQ, then switch to a non-default service by including the Service Selection extension in a subsequent RRQ - that would be why I was confused. I think your explanation is way clearer than the draft text - perhaps you could insert it into the draft text? A new try: At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. The Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. In absence of a specifically indicated service in the Registration Request for the initial binding registration, the home agent MUST act as if the default service, such as plain Internet access had been requested. The absence of the Service Selection extension in a Registration Request that refreshes an existing binding MUST be treated as if the existing service selection is maintained. The Service Selection extension MUST be placed in the Registration
Re: [Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06
Hi, Jouni, Both of these are clearer - thanks for your patience. Spencer Hi Spencer, On Dec 29, 2008, at 6:13 PM, Spencer Dawkins wrote: Hi, Jouni, Thanks for your quick response - I'm OK with most of your proposed changes. I should emphasize that my comments here are Last Call comments that you (and the document shepherd, and the AD) can decide to ignore - I'm just telling you what I'm seeing when I read the text. Just to finish up: Some of the potential use-cases were listed earlier in this section. The general aim is better manageability of services and service provisioning from both operators and service providers point of view. However, it should be understood that there are potential deployment possibilities where selecting a certain service may restrict simultaneous access to other services from an user point of view. For example, services may be located in different administrative domains or external customer networks that practice excessive filtering of inbound and outbound traffic. Spencer: I wasn't clear on who this understanding is directed to - it almost reads like you're warning users that bad things might happen if you use a specific service, but surely the user specifies the service because an operator requires this? We had this discussion earlier on RFC5149.. and concerns were raised whether the Service Selection is a potential tool for enabling walled gardens etc. Thus this note here was added to emphasize that point. I understand your point from your explanation, but can't get that understanding from the draft text. If you said s/from a user point of view/from a user point of view (for example, a walled garden)/ that would be as clear as your explanation. Ok. Thanks. Will add this. 3. Service Selection Extension At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. It SHOULD be included at least in Spencer: seems to be missing a qualifier: When a non-default service is selected, the Service Selection extension SHOULD be included ...? Spencer: If this is qualified, could the SHOULD be a MUST? Hmm.. right. New text would be: At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. The Service Selection extension MUST be placed in the Registration Request message as follows: Spencer: If it remains as SHOULD, what happens if the Service Selection extension is not included in the initial binding registration, but is included in subsequent binding registrations? The first RRQ would be treated as the selection of the default service. The subsequent RRQs with the service selection would cause reauthorization evaluation of the requested service. If the newly requested service conflicts with the default service from the HA point of view, then an appropriate error is returned and the binding is dropped. I'm still confused by When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. My understanding from your explanation is that, by definition, if you don't include the Service Selection extension, you aren't selecting a non-default service until you DO send an RRQ that includes the Service Selection extension - right? If I'm tracking you, you're talking about two cases at the same time - what happens if you DO include the extension in the first RRQ, and what happens if you DON'T include the extension in the first RRQ, then switch to a non-default service by including the Service Selection extension in a subsequent RRQ - that would be why I was confused. I think your explanation is way clearer than the draft text - perhaps you could insert it into the draft text? A new try: At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. The Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. In absence of a specifically indicated service in the Registration Request for the initial binding registration, the home agent MUST act as if the default service, such as plain Internet access had been requested. The absence of the Service Selection extension in a Registration Request that refreshes an existing binding MUST be treated as if the existing service selection is maintained.
Re: [Gen-art] Gen-ART Last Call review of draft-dasgupta-ccamp-path-comp-analysis-02
I added an RFC editor's note to cover these editorial points. Thanks, Ross -Original Message- From: Spencer Dawkins [mailto:spen...@wonderhamster.org] Sent: 25 November 2008 16:34 To: suk...@ece.drexel.edu; j...@ece.drexel.edu; j...@cisco.com Cc: General Area Review Team; Ross Callon; Adrian Farrel; Deborah Brungard Subject: Gen-ART Last Call review of draft-dasgupta-ccamp-path-comp-analysis-02 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 resolve these comments along with any other Last Call comments you may receive. Document: draft-dasgupta-ccamp-path-comp-analysis-02 Reviewer: Spencer Dawkins Review Date: 2008-11-25 IETF LC End Date: 2008-12-14 IESG Telechat date: (not known) Summary: This draft is ready for publication as an Informational RFC. Comments: You can drop the 2119 boilerplate text (because you don't use it). There are some nits (I noticed s/Virutal/Virtual/ and s/Eventhough/Even though/) for the editor. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
