Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Dave CROCKER]

On 4/6/2010 1:39 PM, Scott Lawrence wrote:

On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote:

By title and Introductory text, the document specifies its scope as user agent
configuration by non-technical users.  The actual contents of the specification
suggests a broader scope, also covering automated (non-human) configuration, as
well as the details of a remote "Configuration Service".


I'm not sure what you're asking or suggesting above... the specification
describes automated (or at worst mostly automated) procedures for user
agent configuration, because that's what non-technical users need.  Do
you see a distinction or think that some clarification is needed?


The specification appears to provide for human interaction.  That's not 
automated.

It also appears to provide all the details for the remote service.  Contrary to 
your view that the spec does not provide the details for that service, I'd say 
that it provides quite a bit of such detail.  Perhaps not all that is necessary, 
but quite a bit.


Perhaps the disparity in my assessment and yours is the difference between 
visible versus internal details.  From my perspective, this document provides 
most or all of the external details.  Since the IETF specifies protocol 
behaviors and not internal implementation or internal functional details, that's 
enough to count as an IETF specification.




It even mandates access via HTTPS rather than HTTP, independent of whether other
security mechanisms would suffice.  That is, the document slips into specifying
an integrated service, not just the configuration for a component of that 
service.


Our goal was to specify a simple set of rules that every UA and CS could
implement that would ensure interoperability.


It usually helps to distinguish between the core, essential features versus 
optional ones.  TLS is obviously a respectable choice.  But some environments 
don't need it.  The Subscription feature has utility.  But its implementation 
and operations cost make it appropriate to specify as an option, not a mandated 
universal feature.  (Contrary to Cullen's point, I see this specification as 
mandating the /use/ of that feature, not just its implementation.  The style for 
specifying the distinction is quite different from what's in this document.)



 While we could have put

in some words about how there might exist circumstances in which HTTP
would be appropriate and sufficiently secure, it was our judgement that
such text would not advance the goal.   Yes, if your network is all
glass fiber and has quantum crypto at the physical layer then maybe you
don't need https...


As I suggested in the review, at the least the document should have some 
discourse about its security model, to justify security-related mandatory 
behaviors.  (see below)




Given the significant security-related detail provided in Section 2.4.1, the
security model ought to be called out and discussed in detail, separately.


I'm not clear on what detail you think is missing.


I'm not a security geek but have had the pleasure of interacting with some. 
I've been particularly thrilled to experience the demands of such things as 
documenting a threat model.  But still don't understand the security arena 
(filled with sand, of course) to describe the requirements.  Perhaps a security 
area personage can assist here.  And that assistance might well be to dismiss 
what I'm suggesting -- but I doubt it.




I suggest specifying the details of the remote query service into a separate
section, if not a separate document.  (A separate document would be appropriate
if the configuration service has other plausible clients, besides this one type
of UA.)


The draft as it is is intended to support any SIP UA.  I'm not clear on
which query you mean by 'remote query service' or why it should be
specified anywhere else.


The CS is the remote query service.



Section 2.1

Section 2.1 dictates platform behaviors for network and link-layer
configuration. This kind of detail, in this kind of document, encourages
divergent support, since it specifies details that are normally provided 
elsewhere.

At most, the section should provide a generic reference to "standard" IP support
and leave it at that.  My own suggestion is to say that IP and link
configuration are outside the scope of the document.


Our intent was to specify a profile of "standard" (whatever that means)
IP support; the consensus was that being specific would increase the
likelihood that different implementations and deployments would have the
same expectations.


The desire to do a product specification is understandable.  However that's not 
what the IETF usually standardizes.  For all of the many user-level 
specifications done in the IETF, precious few dictate DHCP details.


In particular, as I said, repeating detail present in other standards 
specifications is a good way to create divergent specifications.  Simply declare 
the use of standards and say no more.

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Dave CROCKER]

On 4/6/2010 10:59 AM, Henning Schulzrinne wrote:

Avalanche (restart) has its own set of problems - including overwhelming
either the HTTP server, SSP or registrar. (In a draft, we've made
proposals how to address this in some cases, as long as the UA can
detect that it is likely part of an avalanche.) As we've seen from the
SIP overload discussion, you can't rely on the "natural" throttling of
the server to nicely space out requests - the whole thing is much more
likely to collapse in a heap,



FWIW, this is a time-honored topic.

In the mid/late 80's, I believe this problem was referred to as the West Point 
problem, since all the cadets would turn on their network-connected PCs at 
exactly 8am.  Ungermann-Bass vs. Bridge Communication had fundamentally 
different network booting models.  One worked well under this sort of load.  One 
didn't.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Ok .. I want my IETF app for my iPad ..

[Byron Ellacott]

It's not an iPad app, but you can see screenshots of the (not App Store 
released) IETF 77 iPhone app I threw together the week before Anaheim:

http://www.flickr.com/photos/dhask/sets/72157623658352428/

I don't have an iPad ("Late April" in Australia), but I don't think it would be 
terribly complex to create an app to cache I-Ds and recent mail archives per WG 
for reading offline.

  Byron

On 04/04/2010, at 7:20 AM, Richard Shockey wrote:

> And I want it now!  Yes I’ll pay thank you.
>  
> Richard Shockey
> Shockey Consulting
> Chairman of the Board of Directors SIP Forum
> PSTN Mobile: +1 703.593.2683
> 
> skype: rshockey101
> LinkedIn : http://www.linkedin.com/in/rshockey101
> http//www.sipforum.org
> 
>  
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

_

Byron Ellacott email:   b...@apnic.net
Technical Area Manager, APNIC  sip:b...@voip.apnic.net
http://www.apnic.net   phone: +61 7 3858 3100

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

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Bernard Aboba]

Hadriel Kaplan said:

 

"Howdy, 
This may not be within the normal rules of etiquette, but I will re-iterate
my issues with this draft which I raised when it was discussed in RAI. 
 
1) The mechanism does not scale, for large SSP's. (is this only meant for
small deployments?)  
 
Expecting every UA to keep a permanent SIP Subscription to "config change"
servers is unreasonable. Either the UA makes this Subscription directly to
the Server(s), in which case there will be a large volume of keep-alives
just to keep NAT pinholes alive; or it makes it through edge proxies, in
which case it's a lot of SIP messaging both in the sense of keeping the
Subscribe dialog alive but more importantly at the worst possible time:
during avalanche restarts. Either way, it's not good. 
 
All this state and signaling is to achieve what? So that once a year or so
we can tell UA's to do another HTTP Get so they change one of their config
settings, or upgrade their firmware?? How is that cost-burden justified? Do
most other applications keep permanent connections for such changes? Not as
far as I can tell. They poll on a (very) infrequent interval. 
 
2) I would be ok with (1) if it was optional, so only providers that wanted
it had to pay for it, but as far as I can tell the mechanism *requires*
implementation of this SIP Subscription service. Maybe I'm reading it wrong?
Section 2.5.1 says the HTTP response MUST have the Link header, with a SIP
URI, and if the Subscription attempt fails then it has to start again, etc.
Seems to me you're requiring/mandating a "nice-to-have-feature", and an
expensive and complicated one at that. Why? 
 
-hadriel "

 

[BA] I agree with your assessment.  This is one of those situations where
(infrequent) polling scales better.   That is how currently most OS update
mechanisms work;  they poll the update servers at intervals orders of
magnitude longer than NAT refresh times (e.g. weekly or daily at most), with
randomized polling times.  That way there is no need to maintain NAT
bindings, and no danger of "flash crowds".   Yes, it might take a while to
bring all the clients up to the latest version, but if you've got any
substantial client population, then you need to spread out the updates
anyway to control the load on the update servers. 

 

In my experience, even where NOTIFY is used to provide update notifications
today, SUBSCRIBE is not.   Yes, that is non-standard, but I think it
demonstrates concern about the overhead relating to SIP
subscription/refresh.  

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

Re: Ok .. I want my IETF app for my iPad ..

[Julian Reschke]

On 06.04.2010 23:48, Mark Nottingham wrote:

It would be even better if the Web in general could support this use case.

The HTML5 folks are designing a client-side data store API, but alas it's not 
connected to the HTTP caching model, so they're effectively making Web authors 
rewrite their sties with JS APIs to make them usable offline -- even though 
HTTP already has a notion of offline cache operation.

But now I'm ranting...


Not yet.

I encourage everybody concerned with this (and similar "progress") to 
join the W3C HTML WG -- it's almost as open as an IETF activity.




Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Public musing on the nature of IETF membership and employment status

[Brian E Carpenter]

On 2010-04-07 05:57, Melinda Shore wrote:
> On Apr 6, 2010, at 9:56 AM, Andrew Sullivan wrote:
>> I thought we didn't have members?  I've always liked to refer to
>> people doing work here as "participants" for exactly that reason.
> 
> Right.

Or "contributors" when they contribute and therefore subject themselves
to our IPR rules.

BTW please look at the paragraph headed "Participation" at
http://www.ietf.org/newcomers.html, which I drafted. Do people
agree with that summary?

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

Re: Ok .. I want my IETF app for my iPad ..

[Mark Nottingham]

It would be even better if the Web in general could support this use case. 

The HTML5 folks are designing a client-side data store API, but alas it's not 
connected to the HTTP caching model, so they're effectively making Web authors 
rewrite their sties with JS APIs to make them usable offline -- even though 
HTTP already has a notion of offline cache operation. 

But now I'm ranting...


On 07/04/2010, at 2:39 AM, Rob Evans wrote:

>> Display RFCs?
>> 
>> Doesn't this new toy of yours already have a browser?
> 
> I was idly thinking of this a few days ago.  An app for the iPad that
> will sync across RFCs and I-Ds for offline viewing would be quite
> useful.
> 
> Rob
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


--
Mark Nottingham http://www.mnot.net/

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

Re: Public musing on the nature of IETF membership and employment status

[ned+ietf]

> Considering that, it wouldn't be the worst idea to have everyone post mailing
> list messages from an employee email address.

Given the stiff competition for "worst idea", I'd agree, but it's a truly
terrible idea nonetheless. The appallingly low quality of the email systems
used by many corporations, nonsensical restrictions and wierd retention
policies, lack of support for incredibly useful functionality like
subaddressing, and numerous other factors make this a complete and total
nonstarter for many.

>  Then again, I don't need that
> kind of spam exposure on even more email addresses...

That barely even makes it onto the issues list.

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

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Scott Lawrence]

> > I do have some problem with making the notification some kind of side
> > effect of the 'normal' registration.  REGISTER exists to map an AOR to
> > one or more Contacts.  The Configuration Service needs to be able to
> > address the change notice (whatever method carries it) to a specific UA,
> > _not_ to the AOR of some user registered to that UA.  

On Tue, 2010-04-06 at 16:41 -0400, Hadriel Kaplan wrote:

> It's not an AoR, it's a gruu. (or could be... I don't care what form
> it takes)

I think that you miss my point.  REGISTER does not identify a UA - it
identifies some AOR.  If we were to define a form of registration that
does identify the UA so that that the configuration service could
address each UA uniquely, that would be a good thing (for this and other
purposes).  

> But it occurs to me I should just shut up and stop trying to argue -
> my company will probably profit nicely from this draft.  ;) 

I have no problem either with you stopping or with your company making a
nice profit :-)  (indeed, the whole point of this is to make SIP
adoption much easier - a rising tide - if your boat floats better than
others, that's fine with me).



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

Gen-ART LC review of draft-ietf-netmod-yang-types-07

[Ben Campbell]

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-ietf-netmod-yang-types-07
Reviewer: Ben Campbell
Review Date: 2010-04-06
IETF LC End Date: 2010-04-09
IESG Telechat date: (if known)

Summary: This draft is almost ready for publication as a proposed standard. 
There are a few minor issues that might should be considered prior to 
publication.

Major issues: None.

Minor issues:

-- Section 3, model namespace definition:

(Same comment for section 4)

Will the registered namespace really include "DRAFT-06"? Should this be 
replaced with the RFC number?

-- description for counter32: "A default statement should not be used for
   attributes with a type value of counter32."

Should that be a normative SHOULD NOT?

-- object-identifier description, 3rd paragraph:

Does this imply a normative requirement that one SHOULD NOT use this to model 
an SMIv2 OI? (and SHOULD instead use object-identifier-128)?

-- Section 4, domain-name, description, paragraph 2: "...systems that want to 
store host names in
   schema nodes using the domain-name type are recommended to
   adhere to this stricter standard to ensure interoperability."

should "recommended" be normative?

Nits/editorial comments:

-- Section 2, 1st paragraph:

Can you provide a reference for SMIv2 (I assume RFC 2578)? Also, please expand 
it on first mention.

-- zero-based-counter32 description, 2nd paragraph:

Plurality mismatch between "nodes" and "it". Suggest s/"Schema nodes"/"A Schema 
node"

-- date-and-time, pattern and description:

Which is the normative description for date-and-time? The ABNF in the 
description, or the pattern attribute? I assume the second, but fear the 
presence of ABNF will make others assume the first.


(Comment repeats for zero-based-counter64)

-- zero-based-counter32 description, 3rd paragraph:

ben: s/"wrap it"/"wrap, it"

(Comment repeats for zero-based-counter64)

-- section 5:

The namespaces do not match the text (see comments on the module namespace 
strings in sections 3 and 4)

-- section 9.2:

idnits complains about unreferenced entries in this section. I'm not sure what 
to do about it, or if it matters at all, since they are referenced from the 
model itself.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Hadriel Kaplan]

> -Original Message-
> From: Scott Lawrence [mailto:xmlsc...@gmail.com]
> Sent: Tuesday, April 06, 2010 2:10 PM
> To: Hadriel Kaplan
> 
> On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote:
> 
> This draft says nothing at all about the ordering of the change notice
> subscription vs any registration.


Oy vey.  The more you keep explaining what the draft does NOT specify, the more 
worried I get. :(

 
> > It's lighter weight because there's no subscription messaging, no
> > permanent dialog state, and even the gruu is constructable and does
> > not need to be stored by the SSP, only by the UA.
> > [sarcasm=on] I don't know why the IETF keeps trying to put state into
> > the middle instead of leaving it in the ends! :) [sarcasm=off]
> 
> I'd be open to a fully worked out proposal based on PUBLISH, but I
> actually don't think that there are big savings over a SUBSCRIBE based
> mechanism.   I don't buy the argument that the dialog state is
> burdensome - it's a few hundred bytes at most (and much of that size is
> under the control of the server).

I think we just have to agree to disagree then.  If you really think having all 
UA's SIP-Subscribe, ad infinitum, is not more expensive and error-prone than 
just sending a single message to it if and only when you need to, then we just 
live in different Worlds.

It's just an informational draft and you don't need to appease me anyway.

 
> I do have some problem with making the notification some kind of side
> effect of the 'normal' registration.  REGISTER exists to map an AOR to
> one or more Contacts.  The Configuration Service needs to be able to
> address the change notice (whatever method carries it) to a specific UA,
> _not_ to the AOR of some user registered to that UA.  

It's not an AoR, it's a gruu. (or could be... I don't care what form it takes)

But it occurs to me I should just shut up and stop trying to argue - my company 
will probably profit nicely from this draft.  ;)

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

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Scott Lawrence]

On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote: 
> Review of:  draft-lawrence-sipforum-user-agent-config

Thanks for taking the time to read this, Dave.

> This appears to be an Individual Submission.

For IETF process purposes that is correct.  As the document says, it is
the product of a design team working within the SIP Forum Technical
Working Group.  

> By title and Introductory text, the document specifies its scope as user agent
> configuration by non-technical users.  The actual contents of the 
> specification
> suggests a broader scope, also covering automated (non-human) configuration, 
> as
> well as the details of a remote "Configuration Service".

I'm not sure what you're asking or suggesting above... the specification
describes automated (or at worst mostly automated) procedures for user
agent configuration, because that's what non-technical users need.  Do
you see a distinction or think that some clarification is needed?

> If the details of the Configuration Service are defined elsewhere I did not 
> find
> citation to it in this draft.  Rather, Section 2.3 appears to imply that 
> remote
> service's HTTP-based query characteristics.

The draft deliberately does not specify anything about the Configuration
Service (CS) other than the protocol interface it supports.   Any other
characteristic of the CS is beyond the scope of the document, and
anything that supports that interface can act as a CS.  Do you think
that's a problem?

> It even mandates access via HTTPS rather than HTTP, independent of whether 
> other
> security mechanisms would suffice.  That is, the document slips into 
> specifying
> an integrated service, not just the configuration for a component of that 
> service.

Our goal was to specify a simple set of rules that every UA and CS could
implement that would ensure interoperability.  While we could have put
in some words about how there might exist circumstances in which HTTP
would be appropriate and sufficiently secure, it was our judgement that
such text would not advance the goal.   Yes, if your network is all
glass fiber and has quantum crypto at the physical layer then maybe you
don't need https...

> Given the significant security-related detail provided in Section 2.4.1, the
> security model ought to be called out and discussed in detail, separately.

I'm not clear on what detail you think is missing.

> I suggest specifying the details of the remote query service into a separate
> section, if not a separate document.  (A separate document would be 
> appropriate
> if the configuration service has other plausible clients, besides this one 
> type
> of UA.)

The draft as it is is intended to support any SIP UA.  I'm not clear on
which query you mean by 'remote query service' or why it should be
specified anywhere else.

> Detailed comments:
> 
> 
> Section 1.1
> 
> Presumably "is free to" should be replaced by MAY, since this is intended to 
> be
> a normative document and statements in a Scope section specify boundaries.

I have no problem with that.

> Section 2.1
> 
> Section 2.1 dictates platform behaviors for network and link-layer
> configuration. This kind of detail, in this kind of document, encourages
> divergent support, since it specifies details that are normally provided 
> elsewhere.
> 
> At most, the section should provide a generic reference to "standard" IP 
> support
> and leave it at that.  My own suggestion is to say that IP and link
> configuration are outside the scope of the document.

Our intent was to specify a profile of "standard" (whatever that means)
IP support; the consensus was that being specific would increase the
likelihood that different implementations and deployments would have the
same expectations.

> Section 2.2
> 
> Is "DNS Name" a domain name or is it a host name?

If I understand your question correctly, it is a domain name.  Given the
usage of the value (section 2.3.1), I think that's clear.

> Section 2.2.1
> 
> > Local Network Domain" is an essential parameter, but is undefined.  The
> > reference to 2.1.2 does not resolve.

Section 2.1.2 (last paragraph) says:

In either case, if the DHCP or DHCPv6 service provides a domain
name value or values for the option concerned, the UA MUST save
those domain names as candidates for use as the Local Network
Domain.

> It is probably also worth confirming that an automatically-supplied domain 
> name
> is an organizational string (DNS suffix) rather than the fully qualified name 
> of
> the UA.

Given that the draft describes the DHCP(v6) option values where this
comes from, I don't understand why anything more might be needed.

> About "network", a term like "local network domain" is probably not as
> meaningful as one might wish, given the decoupling between IP networks and
> Domains.  My guess is that the specification should simply say "local domain".

The draft only uses the term capitalized... and defines that term in
that form as the d

new URN discussion list

[Peter Saint-Andre]

As a venue for discussion about possible revisions to the definition of
Uniform Resource Names (URNs), the IETF Applications Area has created a
new email list u...@ietf.org, to which you can subscribe as follows:

https://www.ietf.org/mailman/listinfo/urn

mailto:urn-requ...@ietf.org?body=subscribe

Please note that the u...@ietf.org list is for discussion regarding the
definition of URNs. We shall continue to use the urn-...@ietf.org list
for review of Namespace Identifiers (NIDs).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Public musing on the nature of IETF membership and employment status

[David Morris]

On Tue, 6 Apr 2010, Dean Willis wrote:
 
> Flip side: I could see the IETF requiring all participants use ietf.org email
> addresses hosted on ietf.org servers with ietf.org-issued
> authentication/signature certificates, and quite possibly (with some
> exceptions) restricted delivery to/from non-IETF addresses.

Not a chance ... making volunteers expend more time to interact using an
isolated mail system would be a major impedament to participation. A
good thing(tm) perhaps?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Hadriel Kaplan]

Sure, but vendors have already spent years working the reg-avalanche problem 
out for subscribers.
One of my fears with this config framework is it's changing it, without a way 
to undo/not-do the change.

-hadriel



From: Henning Schulzrinne [mailto:h...@cs.columbia.edu] 
Sent: Tuesday, April 06, 2010 1:59 PM
To: Hadriel Kaplan
Cc: Cullen Jennings; IETF Discussion Mailing List
Subject: Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session 
Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

Avalanche (restart) has its own set of problems - including overwhelming either 
the HTTP server, SSP or registrar. (In a draft, we've made proposals how to 
address this in some cases, as long as the UA can detect that it is likely part 
of an avalanche.) As we've seen from the SIP overload discussion, you can't 
rely on the "natural" throttling of the server to nicely space out requests - 
the whole thing is much more likely to collapse in a heap, so that no useful 
work gets done. This affects registration, subscription and retrieval more or 
less equally.

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

RE: Public musing on the nature of IETF membership and employment status

[Hadriel Kaplan]

Perhaps that would stop all of these "LOOP MAIL DETECTED" messages I keep 
getting back from kisa.or.kr every time I post to this (particular) email list.
Anyone else getting those?

-hadriel


> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Dean Willis
> Sent: Tuesday, April 06, 2010 3:58 PM
> 
> On Apr 6, 2010, at 2:51 PM, Iljitsch van Beijnum wrote:
> 
> > On 6 apr 2010, at 18:16, Mark Atwood wrote:
> >
> >> Cisco, IBM, MCI, or Linden Lab are not a "members" of the IETF.  No
> >> agency of the US government, or of any other government, is a
> >> "member" of the IETF.  No university, non-profit, PIRG, PAC, or
> >> other "concerned citizens group", is a "member" of the IETF.
> >
> >> Only individual people can be "members" of the IETF.  And
> >> "membership" is mostly defined as "who shows up on the mailing
> >> list" and "who shows up at the meetings".
> >
> > True enough, but that's only one side of the equation. Cisco, IBM,
> > etc, etc as a rule don't send their people to the IETF to support
> > the greater Minneapolis area economy or other alturistic reasons:
> > they want their people to get stuff done at the IETF. As such, an
> > IETF participant's affiliations have relevance, and should be clear
> > to all.
> >
> > Considering that, it wouldn't be the worst idea to have everyone
> > post mailing list messages from an employee email address. Then
> > again, I don't need that kind of spam exposure on even more email
> > addresses...
> 
> And considering the crap that many companies use for email servers,
> their message-deletion policies and so on, I expect there are a lot of
> people who wouldn't want that.
> 
> Flip side: I could see the IETF requiring all participants use
> ietf.org email addresses hosted on ietf.org servers with ietf.org-
> issued authentication/signature certificates, and quite possibly (with
> some exceptions) restricted delivery to/from non-IETF addresses.
> 
> --
> Dean
> 
> ___
> 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: Public musing on the nature of IETF membership and employment status

[Dean Willis]

On Apr 6, 2010, at 2:51 PM, Iljitsch van Beijnum wrote:


On 6 apr 2010, at 18:16, Mark Atwood wrote:

Cisco, IBM, MCI, or Linden Lab are not a "members" of the IETF.  No  
agency of the US government, or of any other government, is a  
"member" of the IETF.  No university, non-profit, PIRG, PAC, or  
other "concerned citizens group", is a "member" of the IETF.


Only individual people can be "members" of the IETF.  And  
"membership" is mostly defined as "who shows up on the mailing  
list" and "who shows up at the meetings".


True enough, but that's only one side of the equation. Cisco, IBM,  
etc, etc as a rule don't send their people to the IETF to support  
the greater Minneapolis area economy or other alturistic reasons:  
they want their people to get stuff done at the IETF. As such, an  
IETF participant's affiliations have relevance, and should be clear  
to all.


Considering that, it wouldn't be the worst idea to have everyone  
post mailing list messages from an employee email address. Then  
again, I don't need that kind of spam exposure on even more email  
addresses...


And considering the crap that many companies use for email servers,  
their message-deletion policies and so on, I expect there are a lot of  
people who wouldn't want that.


Flip side: I could see the IETF requiring all participants use  
ietf.org email addresses hosted on ietf.org servers with ietf.org- 
issued authentication/signature certificates, and quite possibly (with  
some exceptions) restricted delivery to/from non-IETF addresses.


--
Dean

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

Re: Public musing on the nature of IETF membership and employment status

[Iljitsch van Beijnum]

On 6 apr 2010, at 18:16, Mark Atwood wrote:

> Cisco, IBM, MCI, or Linden Lab are not a "members" of the IETF.  No agency of 
> the US government, or of any other government, is a "member" of the IETF.  No 
> university, non-profit, PIRG, PAC, or other "concerned citizens group", is a 
> "member" of the IETF.

> Only individual people can be "members" of the IETF.  And "membership" is 
> mostly defined as "who shows up on the mailing list" and "who shows up at the 
> meetings".

True enough, but that's only one side of the equation. Cisco, IBM, etc, etc as 
a rule don't send their people to the IETF to support the greater Minneapolis 
area economy or other alturistic reasons: they want their people to get stuff 
done at the IETF. As such, an IETF participant's affiliations have relevance, 
and should be clear to all.

Considering that, it wouldn't be the worst idea to have everyone post mailing 
list messages from an employee email address. Then again, I don't need that 
kind of spam exposure on even more email addresses...
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Public musing on the nature of IETF membership and employment status

[Dave Aronson]

On Tue, Apr 6, 2010 at 14:23, Sabahattin Gucukoglu
 wrote:

> I don't see any meaningful relationship between
> employment status and IETF participation.  That's all.

For some of us there is.  I tend to be more active in IETF things
(this list, WGs, etc.) when I'm LOOKING for work!

-Dave

-- 
Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
-+ Play: davearonson.net | \/ Ribbon
"Specialization is for insects." | Life: dare2xl.com | /\ Campaign
-Robert A. Heinlein  | Wife: nasjleti.net| Email<>Web
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Public musing on the nature of IETF membership and employment status

[Donald Eastlake]

On Tue, Apr 6, 2010 at 12:16 PM, Mark Atwood  wrote:

> Much of what makes the IETF work is how it is very different from other
> standards bodies (such as IEEE, ANSI, ISO, NIST, ITU, etc etc).
>
> One key difference is that "groups" do not join the IETF.
>

That's part of it but IEEE, for example, has some standards groups with
Individual membership (for example, both 802.1 and 802.11) and other
standards groups with entity membership.

It is just as big a difference, for the organizations that you list, that
they have reasonably precise rules for becoming a voting member and
maintaining that status, whether the members are individuals or entities.
For individuals, this usually involves meeting attendance and mandatory
response to letter ballots or the like. My status as a voting member of
802.1 and 802.11 is not affected by changes in my employment or affiliation.
Because voting membership is clearly defined, these organizations can do
things by ballot/voting.

The membership of the IETF or any particular IETF working group is not well
defined so decisions are made by some person or group (WG Chair, AD, IESG)
who is empowered to judge rough consensus.

Thanks,
Donald


> Cisco, IBM, MCI, or Linden Lab are not "members" of the IETF.  No agency of
> the US government, or of any other government, is a "member" of the IETF.
>  No university, non-profit, PIRG, PAC, or other "concerned citizens group",
> is a "member" of the IETF.
>
> Only individual people can be "members" of the IETF.  And "membership" is
> mostly defined as "who shows up on the mailing list" and "who shows up at
> the meetings".
>
> There have been many cases in the history of the IETF where well known
> members who are in the middle of writing standards or of chairing various
> important working groups, who have worked for well-known large companies,
> will change employers, to other companies, to startups, or to personal
> sabbaticals switch around between industry, academia, research, and
> government, and this will not, does not, and should not, affect their
> position inside the IETF at all.
>
> It appears that sometimes people, inside and outside of the IETF, need to
> be reminded of this.
>
> If you want to write standards like the IEEE and ITU do it, you know where
> you can find them.
>
> But when you choose to participate in the IETF process, that is how it
> works.
>
> And if someone feels that anyone's change in employment status should
> affect their standing in any part of the IETF process, that person has
> missed the point, and needs to be pointedly reminded of their mistake.
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Public musing on the nature of IETF membership and employment status

[Sabahattin Gucukoglu]

On 6 Apr 2010, at 17:16, Mark Atwood wrote:
> Only individual people can be "members" of the IETF.  And "membership" is 
> mostly defined as "who shows up on the mailing list" and "who shows up at the 
> meetings".
> 
> There have been many cases in the history of the IETF where well known 
> members who are in the middle of writing standards or of chairing various 
> important working groups, who have worked for well-known large companies, 
> will change employers, to other companies, to startups, or to personal 
> sabbaticals switch around between industry, academia, research, and 
> government, and this will not, does not, and should not, affect their 
> position inside the IETF at all.

I don't see any meaningful relationship between employment status and IETF 
participation.  That's all.  As a student and as of now unemployed, I have 
never ceased to be a participant in the IETF, because I have wanted to be a 
participant in the IETF.  And, as far as possible given the necessities of 
life, I think that's how it should be.  We are all a bunch of socialists. :-)

In the meantime my next job might well be decided by first my intrigue of 
networking, and the Internet, and next by my employer's appreciation of these 
same principles.  Until then, my ongoing certification has a lot to do with 
networking.  In any event, it is the IETF's wholly open nature that contributed 
to my involvement and interest in it, and all of the work and people that do 
it, so that it's very possible that these principles are why I'm in this field 
at all.

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

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Scott Lawrence]

On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote:
> 
> > -Original Message-
> > From: Cullen Jennings [mailto:flu...@cisco.com]
> > Sent: Tuesday, April 06, 2010 12:56 PM
> > To: Hadriel Kaplan
> > 
> > > No one has any empirical evidence or experience with what this thing
> > > will do to large subscriber domains. (and by large I mean multiple
> > > millions of UA's, which is the scale several SIP deployments are in now)
> > 
> > I'm aware of deployments with millions of UAs that use subscribe. Agree
> > there are growing points in scaling anything and everything
> 
> 
> Right, but they're doing it for reg-events and presence, after the
> Registration.  During an avalanche, for example, they're implicitly
> throttled by the effective registration rates.  This config framework
> is reversing it, having subscriptions before the registrations.  I'm
> not saying it's not do-able or won't work, I'm just saying we don't
> know. (and I'm saying it's not free, and some folks won't think it's
> worth the cost)

This draft says nothing at all about the ordering of the change notice
subscription vs any registration.

> > > If what we really want is something to force the UA to download a config
> > > *right now*, then do that explicitly.  Give each registered UA a "private"
> > >gruu, known only to the SSP and UA.  When you want to refresh the UA, send
> > > a PUBLISH to the gruu, telling it to refresh its config.  You can do that
> > > gruu statelessly on the SSP side, any number of ways.
> > 
> > I care more there is  a way to do it than how it is done but can you
> > explain how that is lighter weight than a subscribe? 
> 
> One way: when the UA Registers, have the Registrar construct a
> "private" gruu, for example using a hash of the registered contact
> with an unchanging key only known to the registrar. (so no extra state
> in registrar)  Send that gruu back in the Register response with a new
> param name defined in your spec.  The UA stores this private gruu, but
> cannot use it for anything but matching.  The SSP can send an
> out-of-dialog PUBLISH asynchronously, to that contact using the gruu,
> to tell the UA to go get the HTTP config again.
> 
> It's lighter weight because there's no subscription messaging, no
> permanent dialog state, and even the gruu is constructable and does
> not need to be stored by the SSP, only by the UA.
> [sarcasm=on] I don't know why the IETF keeps trying to put state into
> the middle instead of leaving it in the ends! :) [sarcasm=off]

I'd be open to a fully worked out proposal based on PUBLISH, but I
actually don't think that there are big savings over a SUBSCRIBE based
mechanism.   I don't buy the argument that the dialog state is
burdensome - it's a few hundred bytes at most (and much of that size is
under the control of the server).

I do have some problem with making the notification some kind of side
effect of the 'normal' registration.  REGISTER exists to map an AOR to
one or more Contacts.  The Configuration Service needs to be able to
address the change notice (whatever method carries it) to a specific UA,
_not_ to the AOR of some user registered to that UA.  If the UA is going
to REGISTER an AOR for itself that is distinct from that of any user
registered on it, then the whole thing starts to look a lot like a
SUBSCRIBE.   While we did not include text in the draft to suggest the
use of the SIP-Etag mechanism in draft-ietf-sipcore-subnot-etags, it
could be added to suppress the initial NOTIFY associated with the
subscription (and if it would help, I'd have no problem with putting
such text in).


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

Re: Public musing on the nature of IETF membership and employmentstatus

[Paul Ikanza]

I should solicit 7 more so we can have the round figure that is 2010. What a 
coincidence!
Paul
--Original Message--
From: Simon Perreault
Sender: ietf-boun...@ietf.org
To: ietf@ietf.org
Subject: Re: Public musing on the nature of IETF membership and employmentstatus
Sent: Apr 6, 2010 20:58

On 2010-04-06 13:56, Andrew Sullivan wrote:
> I thought we didn't have members?  I've always liked to refer to
> people doing work here as "participants" for exactly that reason.

There are exactly 2003 members of the IETF! ;)

http://www.linkedin.com/groups?viewMembers=&gid=83669

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server--> http://numb.viagenie.ca
vCard 4.0   --> http://www.vcarddav.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


S e n t   f r o m   m y   MTN B l a c k B e r r y ®   s m a r t p h o n e
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Henning Schulzrinne]

> 
> Right, but they're doing it for reg-events and presence, after the 
> Registration.  During an avalanche, for example, they're implicitly throttled 
> by the effective registration rates.  This config framework is reversing it, 
> having subscriptions before the registrations.  I'm not saying it's not 
> do-able or won't work, I'm just saying we don't know. (and I'm saying it's 
> not free, and some folks won't think it's worth the cost)

Avalanche (restart) has its own set of problems - including overwhelming either 
the HTTP server, SSP or registrar. (In a draft, we've made proposals how to 
address this in some cases, as long as the UA can detect that it is likely part 
of an avalanche.) As we've seen from the SIP overload discussion, you can't 
rely on the "natural" throttling of the server to nicely space out requests - 
the whole thing is much more likely to collapse in a heap, so that no useful 
work gets done. This affects registration, subscription and retrieval more or 
less equally.

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

Re: Public musing on the nature of IETF membership and employment status

[Simon Perreault]

On 2010-04-06 13:56, Andrew Sullivan wrote:

I thought we didn't have members?  I've always liked to refer to
people doing work here as "participants" for exactly that reason.


There are exactly 2003 members of the IETF! ;)

http://www.linkedin.com/groups?viewMembers=&gid=83669

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server--> http://numb.viagenie.ca
vCard 4.0   --> http://www.vcarddav.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Public musing on the nature of IETF membership and employment status

[Melinda Shore]

On Apr 6, 2010, at 9:56 AM, Andrew Sullivan wrote:

I thought we didn't have members?  I've always liked to refer to
people doing work here as "participants" for exactly that reason.


Right.

Melinda

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

Re: Public musing on the nature of IETF membership and employment status

[Andrew Sullivan]

On Tue, Apr 06, 2010 at 09:16:41AM -0700, Mark Atwood wrote:
> Only individual people can be "members" of the IETF.

I thought we didn't have members?  I've always liked to refer to
people doing work here as "participants" for exactly that reason.

A
-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Dave CROCKER]

On 4/6/2010 9:55 AM, Cullen Jennings wrote:

This conversation constantly confuses the issue of must implement vs must
deploy. Which one are you objecting to here.



Perhaps you have some data to cite about the historical, real-world difference 
between these?


In a world of legitimately open systems, multiple implementations and competing 
products, there is usually little room for requiring implementation but not 
supporting deployment, I believe.


If you have data to the contrary, please do share it.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Public musing on the nature of IETF membership and employment status

[Mark Atwood]

Much of what makes the IETF work is how it is very different from other
standards bodies (such as IEEE, ANSI, ISO, NIST, ITU, etc etc).

One key difference is that "groups" do not join the IETF.

Cisco, IBM, MCI, or Linden Lab are not a "members" of the IETF.  No agency
of the US government, or of any other government, is a "member" of the IETF.
 No university, non-profit, PIRG, PAC, or other "concerned citizens group",
is a "member" of the IETF.

Only individual people can be "members" of the IETF.  And "membership" is
mostly defined as "who shows up on the mailing list" and "who shows up at
the meetings".

There have been many cases in the history of the IETF where well known
members who are in the middle of writing standards or of chairing various
important working groups, who have worked for well-known large companies,
will change employers, to other companies, to startups, or to personal
sabbaticals switch around between industry, academia, research, and
government, and this will not, does not, and should not, affect their
position inside the IETF at all.

It appears that sometimes people, inside and outside of the IETF, need to be
reminded of this.

If you want to write standards like the IEEE and ITU do it, you know where
you can find them.

But when you choose to participate in the IETF process, that is how it
works.

And if someone feels that anyone's change in employment status should affect
their standing in any part of the IETF process, that person has missed the
point, and needs to be pointedly reminded of their mistake.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Hadriel Kaplan]

> -Original Message-
> From: Cullen Jennings [mailto:flu...@cisco.com]
> Sent: Tuesday, April 06, 2010 12:56 PM
> To: Hadriel Kaplan
> 
> > No one has any empirical evidence or experience with what this thing
> > will do to large subscriber domains. (and by large I mean multiple
> > millions of UA's, which is the scale several SIP deployments are in now)
> 
> I'm aware of deployments with millions of UAs that use subscribe. Agree
> there are growing points in scaling anything and everything


Right, but they're doing it for reg-events and presence, after the 
Registration.  During an avalanche, for example, they're implicitly throttled 
by the effective registration rates.  This config framework is reversing it, 
having subscriptions before the registrations.  I'm not saying it's not do-able 
or won't work, I'm just saying we don't know. (and I'm saying it's not free, 
and some folks won't think it's worth the cost)

 
> > If what we really want is something to force the UA to download a config
> > *right now*, then do that explicitly.  Give each registered UA a "private"
> >gruu, known only to the SSP and UA.  When you want to refresh the UA, send
> > a PUBLISH to the gruu, telling it to refresh its config.  You can do that
> > gruu statelessly on the SSP side, any number of ways.
> 
> I care more there is  a way to do it than how it is done but can you
> explain how that is lighter weight than a subscribe? 

One way: when the UA Registers, have the Registrar construct a "private" gruu, 
for example using a hash of the registered contact with an unchanging key only 
known to the registrar. (so no extra state in registrar)  Send that gruu back 
in the Register response with a new param name defined in your spec.  The UA 
stores this private gruu, but cannot use it for anything but matching.  The SSP 
can send an out-of-dialog PUBLISH asynchronously, to that contact using the 
gruu, to tell the UA to go get the HTTP config again.

It's lighter weight because there's no subscription messaging, no permanent 
dialog state, and even the gruu is constructable and does not need to be stored 
by the SSP, only by the UA.
[sarcasm=on] I don't know why the IETF keeps trying to put state into the 
middle instead of leaving it in the ends! :) [sarcasm=off]


> I would think that a
> subscribe could be done stateless on the SSP too given the usual state in
> dialog information techniques. 

I don't know what you mean?   How can the UAS send a Notify asynchronously 
without having stored the tags, call-id and path info of the subscription 
dialog, created by the UAC/Subscriber?  You can't cookify them anywhere in the 
messaging, for example, because the UAS is the one sending the Notify sometime 
later.
(I'm not referring to SBC's storing the dialog state - I'm talking about the 
config server)


> I get how using a register to form an
> implicit subscribe would reduce the traffic of the initial subscribe
> formation and that might be a interesting optimization for someone to go
> write a draft on.

But why bother with a dialog at all??  The only answer I heard previously was: 
so the UA knows it's the config server, which it trusts.  Well, if a shared 
secret is what we need, then the private gruu is that secret.

-hadriel

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

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Cullen Jennings]

On Apr 6, 2010, at 10:16 AM, Hadriel Kaplan wrote:

> 
> 
> > -Original Message-
> > From: Cullen Jennings [mailto:flu...@cisco.com]
> > Sent: Tuesday, April 06, 2010 11:53 AM
> > To: Hadriel Kaplan
> >
> > However,I did want to comment on the use cases for this. There are many
> > service providers that think it is important to be able to push a new
> > configuration to a UA "quickly" and the definition of quickly varies
> > widely. Imagine the case where someone is having problems getting their
> > fax to work and the SP wants to change the preferred codec from 729 to 711.
> > Now I realize you could do that by using an SBC that forced negation to
> > only 711 but that would reduce the flexibility of the system. Some
> > operators want to be able to change the config on the UA. I have talked to
> > some that seem fine with the idea that the UA would poll ever 24 hours or
> > that the end user user would need to power cycle the UA. I have talked to
> > others that think that is totally unacceptable and need to be able to
> > trigger something that causes the UA to get the new config in something
> > more like 30 seconds. Different folks have different ideas of how fast you
> > need to be able to update this however when you start talking about how
> > fast people would like to roll out fix to a security of DOS attack problem,
> > all the service providers I have talked to start talking about much faster
> > times than 24 hours.
> 
> Right, so what happens if the Subscription *is* the DoS attack?  I'm not 
> saying this to be cute - we need a way to turn it off, and have it off to 
> start with (i.e., on reboot). 
> 
> No one has any empirical evidence or experience with what this thing will do 
> to large subscriber domains. (and by large I mean multiple millions of UA's, 
> which is the scale several SIP deployments are in now)

I'm aware of deployments with millions of UAs that use subscribe. Agree there 
are growing points in scaling anything and everything 

>  As you know, there were several painful "growing pains" in the past in large 
> subscriber domains with unforeseen UA behavior.  Similar issues cropped up 
> again when reg-event Subscriptions started getting deployed.
> 
> If what we really want is something to force the UA to download a config 
> *right now*, then do that explicitly.  Give each registered UA a "private" 
> gruu, known only to the SSP and UA.  When you want to refresh the UA, send a 
> PUBLISH to the gruu, telling it to refresh its config.  You can do that gruu 
> statelessly on the SSP side, any number of ways. 

I care more there is  a way to do it than how it is done but can you explain 
how that is lighter weight than a subscribe? I would think that a subscribe 
could be done stateless on the SSP too given the usual state in dialog 
information techniques. I get how using a register to form an implicit 
subscribe would reduce the traffic of the initial subscribe formation and that 
might be a interesting optimization for someone to go write a draft on. 

> 
> 
> > I'm sure there are some deployments where polling would be fine but there
> > are lots that don't find this acceptable.
> 
> Absolutely - different strokes for different folks.  That doesn't mean 
> everyone should be forced to do it.

This conversation constantly confuses the issue of must implement vs must 
deploy. Which one are you objecting to here. 

> 
> -hadriel
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



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

Re: Ok .. I want my IETF app for my iPad ..

[Rob Evans]

> Display RFCs?
>
> Doesn't this new toy of yours already have a browser?

I was idly thinking of this a few days ago.  An app for the iPad that
will sync across RFCs and I-Ds for offline viewing would be quite
useful.

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

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Scott Lawrence]

On Tue, 2010-04-06 at 09:24 -0700, Dave CROCKER wrote:
> Cullen,
> 
> > I'm sure there are some deployments where polling would be fine but there
> > are  lots that don't find this acceptable.
> 
> 
> The Internet alaredy has quite a bit of experience with renewal of 
> parameters, 
> via DHCP and the DNS.
> 
> What is the justification that mandates a more complex model than
> these use?  It's not usually considered sufficient to simply cite the fact 
> that 
> some operators somewhere want something different.  There needs to be a 
> compelling case made.
> 
> It is always possible to invent edge cases that appear to justify a different
> paradigm.  The real question is about real need.

The configuration data we're discussing here is substantially more
complex and more important to the operation of the device than the
information provided by either DHCP or DNS.  A better analogy would be
the full configuration information for a router - would anyone argue
that only being able to change the configuration of router once every 24
hours would be sufficient?

> Given that operators have survived nicely with the DHCP and DNS models, what 
> is
> the /compelling/ need for doing something differently for the current 
> proposal?
> 
> It will greatly help discussion to have operators represent themselves.  If 
> they 
> really believe the more complex update model is essential, they should lobby 
> for 
> it themselves.  The IETF is nicely open to such participation...

But we can't require it.

The systems I work on are targeted at smaller scales that Hadriel is
arguing for, but the need for prompt (seconds, not minutes)
configuration updates is real for our market.


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

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Dave CROCKER]

Cullen,


I'm sure there are some deployments where polling would be fine but there
are  lots that don't find this acceptable.



The Internet alaredy has quite a bit of experience with renewal of parameters, 
via DHCP and the DNS.


What is the justification that mandates a more complex model than
these use?  It's not usually considered sufficient to simply cite the fact that 
some operators somewhere want something different.  There needs to be a 
compelling case made.


It is always possible to invent edge cases that appear to justify a different
paradigm.  The real question is about real need.

Given that operators have survived nicely with the DHCP and DNS models, what is
the /compelling/ need for doing something differently for the current proposal?

It will greatly help discussion to have operators represent themselves.  If they 
really believe the more complex update model is essential, they should lobby for 
it themselves.  The IETF is nicely open to such participation...


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Hadriel Kaplan]

> -Original Message-
> From: Cullen Jennings [mailto:flu...@cisco.com]
> Sent: Tuesday, April 06, 2010 11:53 AM
> To: Hadriel Kaplan
> 
> However,I did want to comment on the use cases for this. There are many
> service providers that think it is important to be able to push a new
> configuration to a UA "quickly" and the definition of quickly varies
> widely. Imagine the case where someone is having problems getting their
> fax to work and the SP wants to change the preferred codec from 729 to 711.
> Now I realize you could do that by using an SBC that forced negation to
> only 711 but that would reduce the flexibility of the system. Some
> operators want to be able to change the config on the UA. I have talked to
> some that seem fine with the idea that the UA would poll ever 24 hours or
> that the end user user would need to power cycle the UA. I have talked to
> others that think that is totally unacceptable and need to be able to
> trigger something that causes the UA to get the new config in something
> more like 30 seconds. Different folks have different ideas of how fast you
> need to be able to update this however when you start talking about how
> fast people would like to roll out fix to a security of DOS attack problem,
> all the service providers I have talked to start talking about much faster
> times than 24 hours.

Right, so what happens if the Subscription *is* the DoS attack?  I'm not saying 
this to be cute - we need a way to turn it off, and have it off to start with 
(i.e., on reboot).  

No one has any empirical evidence or experience with what this thing will do to 
large subscriber domains. (and by large I mean multiple millions of UA's, which 
is the scale several SIP deployments are in now)  As you know, there were 
several painful "growing pains" in the past in large subscriber domains with 
unforeseen UA behavior.  Similar issues cropped up again when reg-event 
Subscriptions started getting deployed. 

If what we really want is something to force the UA to download a config *right 
now*, then do that explicitly.  Give each registered UA a "private" gruu, known 
only to the SSP and UA.  When you want to refresh the UA, send a PUBLISH to the 
gruu, telling it to refresh its config.  You can do that gruu statelessly on 
the SSP side, any number of ways.  

 
> I'm sure there are some deployments where polling would be fine but there
> are lots that don't find this acceptable.

Absolutely - different strokes for different folks.  That doesn't mean everyone 
should be forced to do it.

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

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Cullen Jennings]

So I agree with Hadriel that we want the document to be very clear on what code 
the implementors need to write but I'm not exactly seeing the confusion. 
Perhaps I need to go reread the doc from that point of view. 


However,I did want to comment on the use cases for this. There are many service 
providers that think it is important to be able to push a new configuration to 
a UA "quickly" and the definition of quickly varies widely. Imagine the case 
where someone is having problems getting their fax to work and the SP wants to 
change the preferred codec from 729 to 711. Now I realize you could do that by 
using an SBC that forced negation to only 711 but that would reduce the 
flexibility of the system. Some operators want to be able to change the config 
on the UA. I have talked to some that seem fine with the idea that the UA would 
poll ever 24 hours or that the end user user would need to power cycle the UA. 
I have talked to others that think that is totally unacceptable and need to be 
able to trigger something that causes the UA to get the new config in something 
more like 30 seconds. Different folks have different ideas of how fast you need 
to be able to update this however when you star
 t talking about how fast people would like to roll out fix to a security of 
DOS attack problem, all the service providers I have talked to start talking 
about much faster times than 24 hours. 

I'm sure there are some deployments where polling would be fine but there are 
lots that don't find this acceptable. 


On Apr 5, 2010, at 3:55 PM, Hadriel Kaplan wrote:

> 
> 
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
>> Scott Lawrence
>> Sent: Monday, April 05, 2010 3:55 PM
>> 
>> On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote:
>>> This form of optional is right up that alley.  For example, if I am a
>>> service provider who wants to not have Subscription mode, and the only
>>> way to do it is through UA config framework itself by setting a config
>>> field for "Subscribe-UA-Config="false" or whatever, then clearly the
>>> UA's MUST use the config.  A MAY statement does nothing.
>> 
>> The draft is clear that the configuration data can modify any part of
>> the procedures in the draft.  Section 2:
>> 
>>The User Agent MAY obtain configuration information by any means
>>in addition to those specified here, and MAY use such
>>information in preference to any of the steps specified
>>below, ...
> 
> But all that statement is "clear" about is that it's NOT clear - not clear 
> what the UA will do, in practice/implementation.  Leaving it up to the UA to 
> decide what to do does nothing to assure the service provider of anything.
> 
> I'm not trying to be difficult (really!) - I'm just asking: imagine I'm a 
> service provider.  I want my users to go into a Best-Buy/Wal-Mart/whatever 
> and buy a SIP phone, plug it into the Internet, download some config stuff 
> from my Apache HTTPS servers, and work.  Can I do that, without having to 
> also deploy SIP Subscription servers?  As I read this doc, I cannot.  
> 
> 
>> So if you're looking for an escape clause, you've found it, but the rest
>> of the sentence is important
>> 
>>...but MUST be capable of using these procedures alone in order
>>to be compliant with this specification.
> 
> 
> Yes, I read that and was thoroughly confused. :)
> 
> 
>> I think that the wording of that particular statement is perhaps
>> unfortunate, but have not found a better one.  In effect, what we were
>> trying to do is express that the UA is not required to wait until the
>> subscription exists to use the data, and can continue to use the data
>> should the subscription fail for any reason.  This prevents various
>> failure modes and/or delays in the UA when the Configuration Service is
>> overloaded or otherwise unavailable.  It's not an 'optional requirement'
>> it's a non-requirement.
> 
> But saying "the UA is not required to do Foo" is NOT the same as saying "the 
> UA is required to not do Foo".  In effect, any and all UA's in the Universe 
> can meet the former, but only some can meet the latter.
> 
> What I mean is, with this language, ALL UA's automatically comply with the 
> RFC, but only *some* will actually use their config without waiting for a 
> subscription.
> 
> -hadriel
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



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

Re: Advance travel info for IETF-78 Maastricht

[Jari Arkko]

Phillip,


This is the main change from the US. In the US it is entirely
practical to carry only plastic and no cash at all.


This is mostly right, but maybe not universally true. Imagine my 
surprise when I walked to a cab at LAX and asked to be taken to the 
Anaheim hotel. First, I had apparently not read enough 77attendees list 
to realize that its a LONG way from the airport. Second, the cab refused 
to take credit cards. I had cash, of course. I was already under the 
impression that paying cabs with cash is necessary in the US. But it 
took a big dent to my cash reserves.


Lessons: 1) its useful to be aware of where you are going and what form 
of transport is appropriate 2) you always need cash, no matter where you 
go. If its not the cab its the coke machine, train or something else.


Jari

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