Re: Gen-ART review of draft-ietf-dime-overload-reqs-12

[Jouni Korhonen]

Thanks David.

- JOuni


On Sep 20, 2013, at 2:57 AM, "Black, David"  wrote:

> And the -12 version is likewise ready for publication as an Informational RFC.
> 
> Thanks,
> --David
> 
>> -Original Message-
>> From: Black, David
>> Sent: Tuesday, August 27, 2013 12:41 PM
>> To: Ben Campbell
>> Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org;
>> d...@ietf.org; bcla...@cisco.com; Black, David
>> Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11
>> 
>> The -11 version of this draft addresses all of the nits and editorial 
>> comments
>> noted in the Gen-ART review of the -10 version.  It's ready for publication 
>> as
>> an Informational RFC.
>> 
>> Thanks,
>> --David
>> 
>>> -Original Message-
>>> From: Ben Campbell [mailto:b...@nostrum.com]
>>> Sent: Thursday, August 22, 2013 4:50 PM
>>> To: Black, David
>>> Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org);
>> ietf@ietf.org;
>>> d...@ietf.org; bcla...@cisco.com
>>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
>>> 
>>> Hi David,
>>> 
>>> We agree on all your points, and will make the updates in the next version,
>>> pending shepherd instructions.
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> 
>>> On Aug 22, 2013, at 2:50 PM, "Black, David"  wrote:
>>> 
 Hi Eric,
 
 This looks good - comments follow ...
 
>> a) I assume that overload control development work will derive more
>>> specific
>> security requirements - e.g., as REQ 27 is stated at a rather high
>> level.
>> The discussion in security considerations section seems reasonable.
> 
> We agree with this.  The thinking here was that we didn't want to specify
>> this
> in a way that would be specific to a particular type of mechanism.  It
>> might
> not hurt to state that assumption, either as a note on Req 27 or in the
>> sec
> considerations.
 
 That would be good to add as a note on REQ 27.
 
> The intent was very much as you say, where requirements on individual
>> node
> capabilities are hoped to result in better overall system behaviors.
>> There are
> also some requirements that are stated more at the system level (e.g. 7
>> and
> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
> insufficient server capacity at a cluster of servers behind a Diameter
>> agent
> can be treated as if the agent itself was overloaded.
> 
> On the other hand, any mechanism we design will have to focus on actions
>> of
> individual nodes, so the numbered requirements tend to focus on that. I'm
>> not
> sure where to change the balance here--do you have specific suggestions?
 
 I noted this as editorial rather than a minor issue, as I was mostly
>> concerned
 that the actual design work will be informed by a sufficient architectural
>> "clue"
 that the goal is "better overall system behaviors", which your response
>> indicates
 will definitely be the case ;-).
 
 Rather than edit individual requirements, how about adding the following
>> sentence
 immediately following the introductory sentence in Section 7?:
 
These requirements are stated primarily in terms of individual node
behavior to inform the design of the improved mechanism;
that design effort should keep in mind that the overall goal is
improved overall system behavior across all the nodes involved,
not just improved behavior from specific individual nodes.
 
>> This inadequacy may, in turn, contribute to broader congestion collapse
>> 
>> "collapse" is not the right word here - I suggest "issues", "impacts",
>> "effects" or "problems".
> 
> We are fine with any of those alternatives.  How about impacts.
 
 That's fine.  FWIW, "congestion collapse" has a specific (rather severe)
 meaning over in the Transport Area, and that meaning was not intended
>> here.
 
> 23.843 is the least stable reference.  I don't have any issue with
>> pointing
> that out.  The part of it we are referencing is historical front matter
> though.
 
 I'd note the reference as work in progress, and put the statement about
>> stable
 front matter (historical is a bad work to use here) in the body of the
>> draft
 that cites the reference.
 
> I tried the web and downloaded versions of 2.12.17 and was not able to
>> get the
> warnings you saw (about the references).  What did it say?
 
 Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits
>> confusion
 manifested right at the top of the output, where everyone ignores it ...
 
  Attempted to download rfc272 state...
  Failure fetching the file, proceeding without it.
 
 You didn't reference RFC 272, so that output's apparently courtesy of
>> idnits
 misinterpreting this reference:
 
 1195  [TS29.272]
 1196

Re: Gen-ART review of draft-ietf-dime-overload-reqs-11

[Jouni Korhonen]

Great. Thanks!


- Jouni


On Aug 27, 2013, at 7:40 PM, "Black, David"  wrote:

> The -11 version of this draft addresses all of the nits and editorial comments
> noted in the Gen-ART review of the -10 version.  It's ready for publication as
> an Informational RFC.
> 
> Thanks,
> --David
> 
>> -Original Message-
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: Thursday, August 22, 2013 4:50 PM
>> To: Black, David
>> Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org;
>> d...@ietf.org; bcla...@cisco.com
>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
>> 
>> Hi David,
>> 
>> We agree on all your points, and will make the updates in the next version,
>> pending shepherd instructions.  
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> On Aug 22, 2013, at 2:50 PM, "Black, David"  wrote:
>> 
>>> Hi Eric,
>>> 
>>> This looks good - comments follow ...
>>> 
> a) I assume that overload control development work will derive more
>> specific
> security requirements - e.g., as REQ 27 is stated at a rather high level.
> The discussion in security considerations section seems reasonable.
 
 We agree with this.  The thinking here was that we didn't want to specify 
 this
 in a way that would be specific to a particular type of mechanism.  It 
 might
 not hurt to state that assumption, either as a note on Req 27 or in the sec
 considerations.
>>> 
>>> That would be good to add as a note on REQ 27.
>>> 
 The intent was very much as you say, where requirements on individual node
 capabilities are hoped to result in better overall system behaviors. There 
 are
 also some requirements that are stated more at the system level (e.g. 7 and
 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
 insufficient server capacity at a cluster of servers behind a Diameter 
 agent
 can be treated as if the agent itself was overloaded.
 
 On the other hand, any mechanism we design will have to focus on actions of
 individual nodes, so the numbered requirements tend to focus on that. I'm 
 not
 sure where to change the balance here--do you have specific suggestions?
>>> 
>>> I noted this as editorial rather than a minor issue, as I was mostly 
>>> concerned
>>> that the actual design work will be informed by a sufficient architectural 
>>> "clue"
>>> that the goal is "better overall system behaviors", which your response 
>>> indicates
>>> will definitely be the case ;-).
>>> 
>>> Rather than edit individual requirements, how about adding the following 
>>> sentence
>>> immediately following the introductory sentence in Section 7?:
>>> 
>>> These requirements are stated primarily in terms of individual node
>>> behavior to inform the design of the improved mechanism;
>>> that design effort should keep in mind that the overall goal is
>>> improved overall system behavior across all the nodes involved,
>>> not just improved behavior from specific individual nodes.
>>> 
> This inadequacy may, in turn, contribute to broader congestion collapse
> 
> "collapse" is not the right word here - I suggest "issues", "impacts",
> "effects" or "problems".
 
 We are fine with any of those alternatives.  How about impacts.
>>> 
>>> That's fine.  FWIW, "congestion collapse" has a specific (rather severe)
>>> meaning over in the Transport Area, and that meaning was not intended here.
>>> 
 23.843 is the least stable reference.  I don't have any issue with pointing
 that out.  The part of it we are referencing is historical front matter
 though.
>>> 
>>> I'd note the reference as work in progress, and put the statement about 
>>> stable
>>> front matter (historical is a bad work to use here) in the body of the draft
>>> that cites the reference.
>>> 
 I tried the web and downloaded versions of 2.12.17 and was not able to get 
 the
 warnings you saw (about the references).  What did it say?
>>> 
>>> Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits 
>>> confusion
>>> manifested right at the top of the output, where everyone ignores it ...
>>> 
>>>  Attempted to download rfc272 state...
>>>  Failure fetching the file, proceeding without it.
>>> 
>>> You didn't reference RFC 272, so that output's apparently courtesy of idnits
>>> misinterpreting this reference:
>>> 
>>> 1195   [TS29.272]
>>> 1196  3GPP, "Evolved Packet System (EPS); Mobility 
>>> Management
>>> 1197  Entity (MME) and Serving GPRS Support Node (SGSN) 
>>> related
>>> 1198  interfaces based on Diameter protocol", TS 29.272 
>>> 11.4.0,
>>> 1199  September 2012.
>>> 
>>> I was amused :-).
>>> 
>>> Thanks,
>>> --David
>>> 
 -Original Message-
 From: Eric McMurry [mailto:emcmu...@computer.org]
 Sent: Thursday, August 22, 2013 3:06 PM
 To: Black, D

Re: call for ideas: tail-heavy IETF process

[Jouni Korhonen]

Jari,

This was an interesting (and a needed) writeup. I also want to share
my view as an IETF newbie who has had a chance to experience IETF
document process a few times. Sorry for chiming in late..

For the most part I got the feeling that we have the right tools and
a working process already in place. It is mostly about how we treat
the process and adjust our habits to it.

The thing I dislike is when you ship a camel into IESG and a horse
comes out.. and everybody is like "what happened?" ;-) My approach
would be simple. If a document gets x DISCUSSes out of y or even a
single DISCUSS would substantially change the technical solution of
the document, ship it back to the WG - always, no questions asked. The
document is not ready and we are wasting IESG's time. The technical
work belongs to the WG. Obviously this begs for a much higher
threshold for an AD to give a document a DISCUSS instead of a COMMENT.

Then about the habits. From my limited experience, folks are used to
the think "the document will anyway be reviewed, reworked and can be
finished in the IESG" and that occasionally shows. I want to believe
this habit changes if the document must be ready for real before
leaving the WG.

The cross area directorate reviews are great and should have even
more weight than they have today. And here is what I would like to
see to change slightly. The directorate & expert reviews should all
be done before sending the document out of the WG into the IESG.
Probably the IETF LC should also happen before sending the document
out of the WG.

My Z$0.02,
Jouni


On May 1, 2013, at 6:33 PM, Jari Arkko  wrote:

> I wrote a blog article about how we do a fairly significant amount of reviews 
> and changes in the late stages of the IETF process. Next week the IESG will 
> be having a retreat in Dublin, Ireland. As we brought this topic to our 
> agenda, Pete and I wanted to raise the issue here and call for feedback & 
> ideas for improving the situation with all of you.
> 
> http://www.ietf.org/blog/2013/05/balancing-the-process/
> 
> Jari
> 

Re: GenART last call review of draft-ietf-behave-nat64-learn-analysis-03

[jouni korhonen]

Roni,

Thanks for the review. We'll take care of the editorials.

- Jouni

On Mar 13, 2012, at 1:24 PM, Roni Even wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> .
> 
>  
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
>  
> Document: draft-ietf-behave-nat64-learn-analysis-03
> Reviewer: Roni Even
> Review Date:2012–3–13
> IETF LC End Date: 2012–3–22
> IESG Telechat date:
>  
> Summary: This draft is ready for publication as an Informational RFC.
>  
> Major issues:
>  
> Minor issues:
>  
> Nits/editorial comments:
>  
> Section 5.1.1 third paragraph change to  “provided by some”
>  
> 

Re: Gen-ART LC/Telechat review of draft-ietf-mext-mip6-tls-03

[Jouni Korhonen]

Thanks Ben for a thorough review. Very good comments indeed. We'll come back
to this in a bit.. you know -00 deadline approaching and such ;)

- Jouni


On 2/29/12 1:34 AM, "ext Ben Campbell"  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-mext-mip6-tls-03
> Reviewer: Ben Campbell
> Review Date: 2012-02-28
> IETF LC End Date: 2012-02-29
> IESG Telechat date: 2012-03-01
> 
> Note: Since the Telechat review deadline is a day before the end of the IETF
> last call, this review serves both as a Telechat review and an IETF Last Call
> review.
> 
> Summary: This draft is basically ready for publication as an experimental RFC.
> There are some clarification issues that might should be addressed prior to
> publication.
> 
> Major issues:
> 
> None
> 
> 
> Minor issues:
> 
> -- general: 
> 
> The draft seems to be missing information on how to match TLS certificates to
> identities for HAC authentication.
> 
> -- section 1, paragraph 1, last sentence: "Client implementation experience
> has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex."
> 
> It might be worth elaborating on why this is true. Could this be solved with a
> cleaner software architecture rather than a protocol change?
> 
> -- section 5.4:  "The actual domain name used in queries is up to the
> deployment to decide and out of scope of this specification."
>  
> This seems under specified for SRV
> 
> -- 5.7.4:
> 
> Are more than one DNS server allowed for each protocol?
> 
> -- 5.8:
> 
> I find this section confusing,as the first and second paragraphs seem to make
> contradictory statements about the authentication, particularly about the use
> of PSK. I think you are talking about authentication of the HAC in the TLS
> handshake vs an higher level authentication of the MN using PSK or EAP. I
> think this could use some clarification, as both paragraphs talks about
> authentication between the MN and HAC without mentioning direction.
> 
> Note that this is more clear in the security considerations section, but it
> would help for it to be more clear here.
> 
> -- 5.9, 2nd to last paragraph:
> 
> How do the first and last sentences relate? It seems to say set it to "1",
> except for this case in which you set it to "1".
> 
> -- 8.1:
> 
> Is this registry only for TLS based MIPv6? If so, does it need to be
> explicitly constrained to not used for MIPv6 in general?
> 
> 
> 
> 
> Nits/editorial comments:
> 
> -- section 4.1: 
> 
> A picture showing the element and key relationships could be helpful here.
> 
> -- section 4.3, third paragraph:
> 
> Please expand BA on first mention
> 
> --section 4.3, "Security association validity times", : "hours or weeks"
> 
> Hours _to_ weeks?
> 
> -- section 4.3, "selected cyphersuite": " The selected algorithms SHOULD be
> one of the mutually supported ciphersuites"
> 
> How could it be otherwise? (i.e. why the SHOULD, and is this really normative
> vs descriptive?)
> 
> -- section 4.4: "Home Agent IP Address" : "Concerns both IPv6 and IPv4 home
> agent addresses."
> 
> Dual stack only?  (same applies to "Home Address" section)
> 
> -- section 5.1, second paragraph: "All data inside the Content portion of the
> message container MUST be encoded using octets."
> 
> I suspect I'm missing a subtlety here--but how else could you do it? Is this
> intended to imply a byte-field, or to imply no additional encoding is used?
> 
> -- section 5.2: "From now on, we use TypeValue header (TV-header) term to
> refer request-response message content HTTP-like headers."
>  
> Maybe that should be moved to the terminology section?
> 
> -- section 5.3, 2nd paragraph: "The MN is also the peer that always sends only
> request messages and the HAC only sends response messages."
> 
> I'm having trouble parsing. Is their a spurious "always"?
> 
> -- section 5.5 : "same to that used by HTTP"
> 
> same _as_?
> 
> -- section 5.5.5
> 
> s/till/until
> 
> -- 5.5.8, 1st sentence:
> 
> Sentence fragment. Missing words?
> 
> -- 5.9, first paragraph:
> 
> Sentence fragment.
> 
> -- 5.9, 2nd to last paragraph:
> 
> s/"In case the"/"In the case that the"
> 
> -- 9:
> 
> A general discussion of threats would be helpful. Some aspects are scattered
> in the subsections, but a summary in one place would be nice.
> 
> -- 9.2: 
> 
> It's not clear to me if the text in the "Dictionary Attack" section is
> actually related to dictionary attacks.
> 
> 
> -- 6.1:
> 
> A picture of the general packet format would be nice. You've got them later
> for specific packet types, but no "general" picture.
> 
> --6.2: 
> 
> Section seems mostly redundant to 6.1
> 
> -- 6.3:
> 
> Please expand HoTI on first use.
> 
> -- 7:
> 
> Please expand CoTI/CoT on first use
> 
> -- 8.3:
> 
> I'm not su

Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime)

[jouni korhonen]

So be it.. from my behalf.

- Jouni

On Jan 16, 2012, at 4:53 PM, Stephen Farrell wrote:

> 
> And I'd be ecstatic (when it happens:-)
> 
> Thanks,
> S
> 
> On 01/16/2012 02:51 PM, Romascanu, Dan (Dan) wrote:
>> This would be fine with me.
>> 
>> Dan
>> 
>> 
>> 
>> 
>>> -Original Message-
>>> From: jouni korhonen [mailto:jouni.nos...@gmail.com]
>>> Sent: Monday, January 16, 2012 4:50 PM
>>> To: Stephen Farrell; Romascanu, Dan (Dan)
>>> Cc: Jouni Korhonen; lionel.mor...@orange-ftgroup.com>  Morand;
>>> d...@ietf.org; IETF-Discussion; i...@ietf.org IESG
>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and
>>> Extensions (dime)
>>> 
>>> Stephen, Dan,
>>> 
>>> What if we just add a milestone to the charter to indicate that
>>> end-to-end security is coming to our table?
>>> 
>>>   Jul 2012 - Sumbit 'problem statement and requirements for Diameter
>>>  end-to-end security framework' as Dime working group
>> item.
>>>   Dec 2012 - Submit 'problem statement and requirements for Diameter
>>>  end-to-end security framework' to the IESG for
>>> consideration
>>>  as an Informational RFC.
>>> 
>>> I would give some time folks to work this out.. and then when we
>>> actually
>>> know what we and especially IETF external deployment folks want, we
>> can
>>> move to  solution part.. Seems like a relaxed milestone plan but I
>> have
>>> doubts it would progress any faster in real life even if milestones
>>> were
>>> tighter ;)
>>> 
>>> - Jouni
>>> 
>>> On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote:
>>> 
>>>> Hi,
>>>> 
>>>> If a number of hands were raised now and the folks commanding them
>>> say
>>>> 'we are ready to work on this NOW' I would support including
>> explicit
>>>> wording in the charter. If this does not happen until the telechat
>>> next
>>>> week the current text is good enough to allow interested people to
>>> start
>>>> working on contributions that can be individual submissions. If
>> these
>>>> submissions are consistent enough the WG can add the milestone later
>>> in
>>>> the charter and adopt the submissions as WG items.
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> -Original Message-
>>>>> From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On
>> Behalf
>>>> Of
>>>>> Stephen Farrell
>>>>> Sent: Thursday, January 12, 2012 2:13 PM
>>>>> To: jouni korhonen
>>>>> Cc: jouni.korho...@nsn.com; lionel.mor...@orange-ftgroup.com;
>>>>> d...@ietf.org; IETF-Discussion; i...@ietf.org
>>>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and
>>>>> Extensions (dime)
>>>>> 
>>>>> 
>>>>> Hi Jouni,
>>>>> 
>>>>> Right, I'm trying to encourage this - I'm not trying
>>>>> to make it a gating function for the recharter. Its
>>>>> still worth doing though if we can find some victims
>>>>> with enough energy:-)
>>>>> 
>>>>> I agree that the current charter text might not need
>>>>> to be modified, OTOH, if there were folks who wanted to
>>>>> do the work, a milestone might be good. I also agree
>>>>> that as of now, that addition is not warranted.
>>>>> 
>>>>> Cheers,
>>>>> S
>>>>> 
>>>>> On 01/12/2012 12:08 PM, jouni korhonen wrote:
>>>>>> 
>>>>>> Stephen,
>>>>>> 
>>>>>> This topic raises its head every now and then when a Dime
>>>>>> document arrives at IESG ;) Apart from that there has been
>>>>>> very little serious public discussion about it recently,
>>>>>> for some unknown reason to me. A detail worth pointing out
>>>>>> is that the support for the End-to-End security framework
>>>>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been
>>>>>> deprecated in RFC3588bis (now in IESG). So we are "free"
>>>>>> to start from sc

Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime)

[jouni korhonen]

Stephen, Dan,

What if we just add a milestone to the charter to indicate that
end-to-end security is coming to our table? 

  Jul 2012 - Sumbit 'problem statement and requirements for Diameter
 end-to-end security framework' as Dime working group item.
  Dec 2012 - Submit 'problem statement and requirements for Diameter
 end-to-end security framework' to the IESG for consideration
 as an Informational RFC.

I would give some time folks to work this out.. and then when we actually
know what we and especially IETF external deployment folks want, we can
move to  solution part.. Seems like a relaxed milestone plan but I have
doubts it would progress any faster in real life even if milestones were
tighter ;)

- Jouni

On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote:

> Hi,
> 
> If a number of hands were raised now and the folks commanding them say
> 'we are ready to work on this NOW' I would support including explicit
> wording in the charter. If this does not happen until the telechat next
> week the current text is good enough to allow interested people to start
> working on contributions that can be individual submissions. If these
> submissions are consistent enough the WG can add the milestone later in
> the charter and adopt the submissions as WG items. 
> 
> Dan
> 
> 
> 
> 
> 
>> -Original Message-
>> From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On Behalf
> Of
>> Stephen Farrell
>> Sent: Thursday, January 12, 2012 2:13 PM
>> To: jouni korhonen
>> Cc: jouni.korho...@nsn.com; lionel.mor...@orange-ftgroup.com;
>> d...@ietf.org; IETF-Discussion; i...@ietf.org
>> Subject: Re: WG Review: Recharter of Diameter Maintenance and
>> Extensions (dime)
>> 
>> 
>> Hi Jouni,
>> 
>> Right, I'm trying to encourage this - I'm not trying
>> to make it a gating function for the recharter. Its
>> still worth doing though if we can find some victims
>> with enough energy:-)
>> 
>> I agree that the current charter text might not need
>> to be modified, OTOH, if there were folks who wanted to
>> do the work, a milestone might be good. I also agree
>> that as of now, that addition is not warranted.
>> 
>> Cheers,
>> S
>> 
>> On 01/12/2012 12:08 PM, jouni korhonen wrote:
>>> 
>>> Stephen,
>>> 
>>> This topic raises its head every now and then when a Dime
>>> document arrives at IESG ;) Apart from that there has been
>>> very little serious public discussion about it recently,
>>> for some unknown reason to me. A detail worth pointing out
>>> is that the support for the End-to-End security framework
>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been
>>> deprecated in RFC3588bis (now in IESG). So we are "free"
>>> to start from scratch.
>>> 
>>> If there is enough serious energy and vision for pursuing
>>> end-to-end security, I do not see current proposed charter
>>> text prohibiting it:
>>> 
>>> "- Maintaining and/or progressing, along the standards track, the
>>>Diameter Base protocol and Diameter Applications. This includes
>>>extensions to Diameter Base protocol that can be considered as
>>>enhanced features or bug fixes."
>>> 
>>> I would argue the end-to-end security is an enhanced feature for
>>> Diameter base protocol that fixes a serious bug/flaw in security.
>>> On the other hand, if an explicit note is needed about this topic
>>> in the charter, I might hesitate to include such in this round.
>>> I would first like to see some concrete movement&  work around
>>> this topic.
>>> 
>>> - Jouni
>>> 
>>> 
>>> 
>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote:
>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> During the IESG internal review of this I asked whether
>>>> or not there was interest in trying to tackle end to
>>>> end security for AVPs. I do know there is at least some
>>>> interest in that but its not clear there's enough to
>>>> warrant including it in the re-charter so I said I'd
>>>> ask when the recharter went out for review...
>>>> 
>>>> So - anyone interested in DIME solving that problem?
>>>> (And willing and able to help do the work of course.)
>>>> 
>>>> As of now, Diameter really only has hop-by-hop security
>>>> which is ok in many cases but far f

Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime)

[jouni korhonen]

Stephen,

This topic raises its head every now and then when a Dime 
document arrives at IESG ;) Apart from that there has been
very little serious public discussion about it recently,
for some unknown reason to me. A detail worth pointing out
is that the support for the End-to-End security framework
(E2E-Sequence AVP and 'P'-bit in the AVP header) has been
deprecated in RFC3588bis (now in IESG). So we are "free"
to start from scratch. 

If there is enough serious energy and vision for pursuing
end-to-end security, I do not see current proposed charter
text prohibiting it:

"- Maintaining and/or progressing, along the standards track, the
   Diameter Base protocol and Diameter Applications. This includes
   extensions to Diameter Base protocol that can be considered as
   enhanced features or bug fixes."

I would argue the end-to-end security is an enhanced feature for
Diameter base protocol that fixes a serious bug/flaw in security.
On the other hand, if an explicit note is needed about this topic
in the charter, I might hesitate to include such in this round.
I would first like to see some concrete movement & work around
this topic.

- Jouni



On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote:

> 
> Hi,
> 
> During the IESG internal review of this I asked whether
> or not there was interest in trying to tackle end to
> end security for AVPs. I do know there is at least some
> interest in that but its not clear there's enough to
> warrant including it in the re-charter so I said I'd
> ask when the recharter went out for review...
> 
> So - anyone interested in DIME solving that problem?
> (And willing and able to help do the work of course.)
> 
> As of now, Diameter really only has hop-by-hop security
> which is ok in many cases but far from ideal (wearing
> my security hat) in some.
> 
> Thanks,
> Stephen.
> 
> On 01/11/2012 04:37 PM, IESG Secretary wrote:
>> A modified charter has been submitted for the Diameter Maintenance and
>> Extensions (dime) working group in the Operations and Management Area of
>> the IETF.  The IESG has not made any determination as yet.  The modified
>> charter is provided below for informational purposes only.  Please send
>> your comments to the IESG mailing list (i...@ietf.org) by Wednesday,
>> January 18, 2012.
>> 
>> Diameter Maintenance and Extensions (dime)
>> -
>> Current Status: Active
>> 
>> Last Modified: 2012-01-10
>> 
>> Chairs:
>> Lionel Morand
>> Jouni Korhonen
>> 
>> Operations and Management Area Directors:
>> Dan Romascanu
>> Ronald Bonica
>> 
>> Operations and Management Area Advisor:
>> Dan Romascanu
>> 
>> Mailing Lists:
>> General Discussion: d...@ietf.org
>> To Subscribe:   https://www.ietf.org/mailman/listinfo/dime
>> Archive:
>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html
>> 
>> Description of Working Group:
>> 
>> The Diameter Maintenance and Extensions WG will focus on maintenance and
>> extensions to the Diameter protocol required to enable its use for
>> authentication, authorization, accounting, charging in network access,
>> provisioning of configuration information within the network, and for
>> new AAA session management uses within the extensibility rules of the
>> Diameter base protocol.
>> 
>> The DIME working group plans to address the following items:
>> 
>> - Maintaining and/or progressing, along the standards track, the
>> Diameter Base protocol and Diameter Applications. This includes
>> extensions to Diameter Base protocol that can be considered as enhanced
>> features or bug fixes.
>> 
>> - Diameter application design guideline. This document will provide
>> guidelines for design of Diameter extensions. It will detail when to
>> consider reusing an existing application and when to develop a new
>> application.
>> 
>> - Protocol extensions for the management of Diameter entities. This work
>> focuses on the standardization of Management Information Bases (MIBs) to
>> configure Diameter entities (such as the Diameter Base protocol or
>> Diameter Credit Control nodes). The usage of other management protocols
>> for configuring Diameter entities may be future work within the group.
>> 
>> - Protocol extensions for bulk and grouped AAA session management. The
>> aim of this work is to study and standardize a solution for handling
>> groups of AAA sessions within the Diameter base protocol context. The
>> solution would define how to identify and handle grouped AAA sessions i

Re: Review of draft-ietf-nextext-radius-pmip6

[jouni korhonen]

On Jan 11, 2012, at 9:04 AM, Bernard Aboba wrote:

> Message-Authenticator should be mandatory (1 1 1 1).

Ack. Thanks Bernard.

- Jouni




> 
> 
> On Jan 10, 2012, at 22:30, "jouni korhonen"  wrote:
> 
>> Bernard,
>> 
>> Thank you for your review. See my comments inline.
>> 
>> 
>> On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote:
>> 
>>> The document appears to contain typos in sections 4.16 and 4.17.   
>>> 
>>> In section 4.16, it appears that "Home LMA IPv6 address" should be replaced 
>>> by "Home DHCPv6 server address":
>> 
>> Blimey.. we'll fix this.
>> 
>>> 4.16.  PMIP6-Home-DHCP6-Server-Address
>>> 
>>> 
>>> 
>>>   0   1   2   3
>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>  |  Type |   Length  |  Home DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>Home DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>Home DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>Home DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   Home LMA IPv6 address  |
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 
>>> In Section 4.17, it appears that "Visited LMA IPv6 address" should be 
>>> replaced by "Visited DHCPv6 server address":
>> 
>> And the same here..
>> 
>> 
>>> 
>>> 4.17.  PMIP6-Visited-DHCP6-Server-Address
>>> 
>>> 
>>>   0   1   2   3
>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>  |  Type |   Length  | Visited DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   Visited DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   Visited DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   Visited DHCPv6 server address
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> Visited LMA IPv6 address |
>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 
>>> 
>>> 5.2.  Table of Attributes
>>> 
>>> 
>>>  The following table provides a guide to attributes that may be found
>>>  in authentication and authorization RADIUS messages between MAG and
>>>  the AAA Server.
>>> 
>>> 
>>> Request Accept Reject Challenge #  Attribute
>>> 
>>>  0-1 0-10-10-1  80  Message-Authenticator
>>> 
>>> 
>>> 
>>> [BA] The Message-Authenticator attribute is mandatory-to-implement in a 
>>> number of 
>>> RADIUS usages, including EAP (RFC 3579).  Leaving out Message-Authenticator 
>>> could 
>>> result in Access-Requests lacking authentication and
>>> integrity protection.  RFC 6158 Section 3.1 states:
>> 
>> Good point. So, you are saying that we should have:
>> 
>>  1   0-10-10-1  80  Message-Authenticator
>> 
>> or would 
>> 
>>  1   1  1  180  Message-Authenticator
>> 
>> be even better as RFC3759 & 5090 do?
>> 
>> 
>> - Jouni
>> 
>> 
>> 
>>> 
>>>  While [RFC2865] did not require authentication and integrity
>>>  protection of RADIUS Access-Request packets, subsequent
>>>  authentication mechanism specifications, such as RADIUS/EAP [RFC3579]
>>>  and Digest Authentication [RFC5090], have mandated authentication and
>>>  integrity protection for certain RADIUS packets.  [RFC5080], Section
>>>  2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
>>>  including Access-Request packets performing authorization checks.  It
>>>  is expected that specifications for new RADIUS authentication
>>>  mechanisms will continue this practice.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of draft-ietf-nextext-radius-pmip6

[jouni korhonen]

Bernard,

Thank you for your review. See my comments inline.


On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote:

> The document appears to contain typos in sections 4.16 and 4.17.   
> 
> In section 4.16, it appears that "Home LMA IPv6 address" should be replaced 
> by "Home DHCPv6 server address":

Blimey.. we'll fix this.

> 4.16.  PMIP6-Home-DHCP6-Server-Address
> 
> 
> 
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Type |   Length  |  Home DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  Home DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  Home DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  Home DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Home LMA IPv6 address  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> In Section 4.17, it appears that "Visited LMA IPv6 address" should be 
> replaced by "Visited DHCPv6 server address":

And the same here..


> 
> 4.17.  PMIP6-Visited-DHCP6-Server-Address
> 
> 
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Type |   Length  | Visited DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Visited DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Visited DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Visited DHCPv6 server address
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   Visited LMA IPv6 address |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 5.2.  Table of Attributes
> 
> 
>The following table provides a guide to attributes that may be found
>in authentication and authorization RADIUS messages between MAG and
>the AAA Server.
> 
> 
> Request Accept Reject Challenge #  Attribute
> 
>0-1 0-10-10-1  80  Message-Authenticator
> 
> 
> 
> [BA] The Message-Authenticator attribute is mandatory-to-implement in a 
> number of 
> RADIUS usages, including EAP (RFC 3579).  Leaving out Message-Authenticator 
> could 
> result in Access-Requests lacking authentication and
> integrity protection.  RFC 6158 Section 3.1 states:

Good point. So, you are saying that we should have:

   1   0-10-10-1  80  Message-Authenticator

or would 

   1   1  1  180  Message-Authenticator

be even better as RFC3759 & 5090 do?


- Jouni



> 
>While [RFC2865] did not require authentication and integrity
>protection of RADIUS Access-Request packets, subsequent
>authentication mechanism specifications, such as RADIUS/EAP [RFC3579]
>and Digest Authentication [RFC5090], have mandated authentication and
>integrity protection for certain RADIUS packets.  [RFC5080], Section
>2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
>including Access-Request packets performing authorization checks.  It
>is expected that specifications for new RADIUS authentication
>mechanisms will continue this practice.
> 
> 
>  
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] Last Call: (IPv6 in 3GPP Evolved Packet System) to Informational RFC

[jouni korhonen]

Dear Gang,

On Aug 9, 2011, at 7:14 PM, GangChen wrote:

> Dear Jouni,
> 
> In mobile CPE case, MT and TE are separated. That would need
> additional requirements in some particular cases, e.g. dynamic IPv6
> address allocation.

Separate MT & TE is part of the existing 3GPP specifications. There is nothing 
CPE specific in that.

> According to the 3GPP specification, the UE shall build the link-local
> address using the interface identifier provided by the PDN GW upon PDN
> connection establishment. However, MT may not be able to transfer the
> interface identifier to TE in the CPE cases. The only thing the IP

See my earlier mail: 
http://www.ietf.org/mail-archive/web/v6ops/current/msg10213.html
This is again not specific to a CPE case but rather a driver framework 
brokenness issue.

> devices can do is to select the interface identifier by some other
> means and then perform Duplicate Address Detection, as specified in
> RFC 4862. The PDN GW shall then perform the DAD check based on the
> Neighbor Solicitation messages sent by the UE.

A GGSN/PPGW is already supposed to perform a DAD check. Referring to 3GPP 
TS29.061 Section 11.2.1.3.4, which says:
"For IPv6 Address Autoconfiguration to work properly, network entities which 
act as an access router towards the MS/UE, i.e. PDN GW, Serving GW, and ePDG, 
shall be consistent with the RFCs specifying this process (for example RFC 4862 
[83] and RFC 4861 [89]), unless stated otherwise in this or other 3GPP 
specifications."

And there is no text in specs that would state using "shall" that the 
PGW/GGSN/SGW must not perform DAD check or not to answer to an NS.. on a 
contrary (see text in Section 11.2.3.2 & 11.2.3.2a.. not that the text is the 
best regarding handling an NS but still).

> Therefore, there are some implementation factors that may change UE
> behaviour in the CPE context. IMHO, it would be beneficial to describe
> CPE consideration in section 5.3. CPE case has already appeared to be
> a valid scenario in 3GPP

I still cannot see any CPE specific considerations here. I witness same thing 
almost daily with my 3G dongle, which was the reason for 
http://www.ietf.org/mail-archive/web/v6ops/current/msg10213.html.

- Jouni

> 
> BRs
> 
> Gang
> 
> 2011/8/5, Jouni :
>> Dear Gang,
>> 
>> I would be inclined to say that within the 3GPP scope the client is always
>> the "UE" and its form factor or the end usage scenario does not really
>> matter. It does not change the way the UE is expected to behave from the
>> 3GPP system point of view, unless there is a new functional requirement from
>> 3GPP.
>> 
>> - Jouni
>> 
>> 
>> 
>> On Aug 5, 2011, at 5:55 AM, GangChen wrote:
>> 
>>> Hello Authors,
>>> 
>>> I think it is worth adding some texts to describe mobile CPE case, in
>>> which CPEs with wireless modem use 3GPP access as uplink.
>>> 
>>> Gang
>>> 
>>> 
>>> 2011/8/2, The IESG :
 
 The IESG has received a request from the IPv6 Operations WG (v6ops) to
 consider the following document:
 - 'IPv6 in 3GPP Evolved Packet System'
  as an Informational RFC
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 Abstract
 
 
  Use of data services in smart phones and broadband services via HSPA
  and HSPA+, in particular Internet services, has increased rapidly and
  operators that have deployed networks based on 3GPP network
  architectures are facing IPv4 address shortages at the Internet
  registries and are feeling a pressure to migrate to IPv6.  This
  document describes the support for IPv6 in 3GPP network
  architectures.
 
 
 
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/
 
 
 No IPR declarations have been submitted directly on this I-D.
 
 
 ___
 v6ops mailing list
 v6...@ietf.org
 https://www.ietf.org/mailman/listinfo/v6ops
 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART Review of draft-ietf-dime-pmip6-02.txt

[jouni korhonen]

Hi Spencer,

Thanks for the review. See my responses inline.


On Aug 4, 2009, at 10:45 PM, Spencer Dawkins wrote:

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-dime-pmip6-02.txt
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-08-05
Review Date: 2009-08-03
IESG Telechat date: (not known)

Summary: This specification is almost ready for publication as a  
Proposed Standard. I have some minor comments, mostly involving 2119  
language.


1.  Introduction

 This specification defines the Diameter support for PMIPv6.  In the
 context of this specification the location of the subscriber policy
 profile equals to the home Diameter server, which is also referred as

Spencer (clarity): this sentence is difficult to parse - is it  
saying "In this specification, the home Diameter server, which is  
also referred to as the home AAA server (HAAA), contains the  
subscriber policy profile"? If it doesn't, I'm too confused to make  
a suggestion...


How about:

In the context of this specification the home AAA server (HAAA)
functionality is co-located with the subscriber policy profile.




 the home AAA server (HAAA).  The NAS functionality of the MAG may be
 co-located or an integral part of the MAG.

4.5.  MIP6-Feature-Vector AVP

 LOCAL_MAG_ROUTING_SUPPORTED (0x0400)

Direct routing of IP packets between MNs anchored to the same MAG
is supported.  When a MAG sets this bit in the MIP6-Feature-
Vector, it indicates that routing IP packets between MNs anchored
to the same MAG is supported, without reverse tunneling packets
via the LMA or requiring any Route Optimization related signaling
(e.g. the Return Routability Procedure in [RFC3775]) prior direct
routing.  If this bit is unset in the returned MIP6-Feature-Vector

Spencer (clarity): I'd say "if this bit is cleared".


OK.




AVP, the HAAA does not authorize direct routing of packets between
MNs anchored to the same MAG.  This policy feature SHOULD be
supported per MN and subscription basis.

Spencer (minor): it's not clear who SHOULD be supporting this  
feature - who does the 2119 SHOULD apply to? I would guess it  
applies to the MAG, but I'm guessing. Is this "supported on a per-MN  
and per-subscription basis"? And I'm not sure why this SHOULD isn't  
a MUST.


"supported on a per-MN and per-subscription basis" is what the text  
tries to say.


It is SHOULD as the RFC5213 does not mandate whether the local routing  
is per-MN (uses MAY in RFC5213) or applies to whole MAG. Therefore, we  
felt SHOULD is enough and final decision is then left for the  
deployment/system.





4.8.  Service-Selection AVP

 It is also possible that the MAG receives the service selection
 information from the MN, for example, via some lower layer mechanism.
 In this case the MAG SHOULD include the Service-Selection AVP also in

Spencer (minor): why is this a SHOULD, and not a MUST?


I would be fine with MUST here.




 the MAG-to-HAAA request messages.  In absence of the Service-
 Selection AVP in the MAG-to-HAAA request messages, the HAAA may want
 to inform the MAG of the default service provisioned to the MN and
 include the Service-Selection AVP in the response message.

5.1.  MAG-to-HAAA Interface

 Whenever the MAG sends a Diameter request message to the HAAA the
 User-Name AVP SHOULD contain the MN's identity.  The MN identity, if

Spencer (minor): what is this SHOULD conditional on?


In case of identity hiding is applied, the User-Name can be absent.



 available, MUST be in Network Access Identifier (NAI) [RFC4282]
 format.  At minimum the home realm of the MN MUST be available at the
 MAG when the network access authentication takes place.  Otherwise
 the MAG is not able to route the Diameter request messages towards
 the correct HAAA.  The MN identity used on the MAG-to-HAAA interface
 and in the User-Name AVP MAY entirely be related to the network
 access authentication, and therefore not suitable to be used as the
 MN-ID mobility option value in the subsequent PBU/PBA messages.  See
 the related discussion on MN's identities in Section 4.6 and in
 Section 5.2.1

Spencer (nit): missing period here.


OK.



5.2.1.  Authorization of the Proxy Binding Update

 Whenever the LMA sends a Diameter request message to the HAAA, the
 User-Name AVP SHOULD contain the MN's identity.  The LMA MAY retrieve

Spencer (minor): what is this SHOULD conditional on?


The "profile" for LMA-HAAA proposed in this specification is going to  
be used on top of some other application. That some other application  
may not use User-Name, thus we felt SHOULD is strong enough to give  
guidance to do so..




 the MN's identity information from the PBU MN-I

Re: Last Call: draft-jones-dime-3gpp-eps-command-codes (Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)) to Informational RFC

[jouni korhonen]

Hi Cullen,

This is what the forthcoming RFC3588bis will do. Vendor-specific  
commands, like the 3GPP ones in this case, would be allocated on a  
First Come, First Served basis by IANA. However, for this specific  
request, RFC3588bis won't be ready/published soon enough.


Cheers,
Jouni

On Feb 11, 2009, at 5:27 AM, Cullen Jennings wrote:



My understanding is that this registry requires "IETF Consensus" as  
defined in 2434. However, theses registration are being defined by  
3GPP TS 29.272 which does not have IETF Consensus. If the DIME  
community wishes to allow registrations like this, why not update  
the IANA registration process to be "Specification Required"?



On Feb 5, 2009, at 7:17 AM, The IESG wrote:

The IESG has received a request from an individual submitter to  
consider

the following document:

- 'Diameter Command Code Registration for Third Generation  
Partnership

 Project (3GPP) Evolved Packet System (EPS) '
  as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to  
the

ietf@ietf.org mailing lists by 2009-03-05. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-jones-dime-3gpp-eps-command-codes-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18081&rfc_flag=0

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART Last Call review of draft-korhonen-mip4-service-06

[jouni korhonen]

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 Registrat

Re: Gen-ART Last Call review of draft-korhonen-mip4-service-06

[jouni korhonen]

Hi Spencer,

Thanks for the review! See some comments inline.

On Tue, Dec 2, 2008 at 11:18 PM, Spencer Dawkins
<[EMAIL PROTECTED]> wrote:
>
> 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-korhonen-mip4-service-06
> Reviewer: Spencer Dawkins
> Review Date: 2008-12-02
> IETF LC End Date: 2008-12-24
> IESG Telechat date: (not known)
> Summary: This draft is on the right track for publication as Informational 
> (should it be standards-track, if you're expecting this to be widely 
> deployed? But I'll leave that to the IESG).

I would have nothing against standards track RFC.

>
> I do have comments, especially involving 2119 language.
>
> Comments:
>
> (Can Jouni's e-mail address really be
>  Email: [EMAIL PROTECTED]
> ?)

Yes, this is my valid gmail e-mail address ;)

>
> 1.  Introduction
>
>  This document describes a Service Selection Extension for Mobile IPv4
>  that is intended to assist home agents to make specific service
>  selections for the mobility service subscription during the
>  registration procedure.  The service selection may affect home agent
>  routing decisions, Home Address assignment policies, firewall
>  settings, and security policies.  The Service Selection extension
>  SHOULD be used in every Registration Request that makes a new
>  registration to the home agent.  The Service Selection extension from
>  the Registration Request MAY be echoed back in the Registration
>  Reply.
>
> Spencer: I don't usually see 2119 normative language in the introduction of 
> Internet Drafts... at a minimum, these statements appear before the 
> requirements key words are introduced in section 2. I THINK most of these 
> requirements are restated later in the document anyway, so they could 
> probably be dropped here.

Ok, good point. I'll will remove the 2119 language from the Introduction.


>
>  In absence of a specifically indicated service the home agent MUST
>  act as if the default service, plain Internet access had been
>  requested.  There is no absolute requirement that this default
>  service be allowed to all subscribers, but it is highly RECOMMENDED
>  in order to avoid having normal subscribers employ operator-specific
>  configuration values in order to get basic service.
>
>  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.

>
>
> 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 bindi