> -----Original Message-----
> From: Cullen Jennings [mailto:[email protected]]
> Sent: Thursday, November 29, 2007 10:42 PM
> To: ECRIT
> Subject: [Ecrit] draft-ietf-ecrit-phonebcp-03
> I find things like AN-15 pretty confusing about what they mean I
> should do
> AN-15 Placement of NAT devices SHOULD consider the effect of the NAT
> on the LCP.
> I don't know what I would do with this - to me it roughly says "Some
> network configurations will not work, and we can't tell you which
> ones. Try to avoid them - Good Luck". I have similar feelings about
> some of the other requirements. I guess all I am saying is have a
> read over these and see if they can be changed to something an
> implementation needs to do.
Okay, but it DOES matter; if you put a NAT in someplace where it will screw
up location, you are creating a problem, so network design needs to take
into account the LIS location.
Can you suggest a better way to say that?
> Some trivial stuff ...
> In section 10
> SP-37 Unitialized devices SHOULD have a persistent URI in a
> P-Asserted-Identity: header if there is some way to assign such an
> identifier to the device.
> Why bother - I can't imagine that the unitialized device is part of
> Trust Domain and the first thing the proxy would do would be toss out
> this information and replace it with authenticated information. When
> I read this, I suspect this is somewhat confused about when 3325
> works. I point out that it is an information RFC because it only
> worked in fairly limited circumstances - I suspect this is one of the
> environments where it does not work.
So, the idea is that normally, unitialized devices wouldn't have a
persistent ID. However, once you make an emergency call, it may be possible
to assign one for a while (days) so call back works.
Suppose you had a set of TNs that could be allocated for days at a time for
this purpose. 3325 would work if the identifier was a telephone number,
which it usually is, or it only used the identifier within the domain of the
calling network, which is going to be possible in most cases, and probably
can be at least temporarily arranged in extreme cases.
> ED-40 says that 3118 should be used but I have no idea how you are
> going to get credentials for this is many of the cases you are
> interested in. In fact exactly the case where DHCP is most likely to
> be spoofed.
> In ED-33, I don't think you want to ref 3118.
I'll look at this again. Suggestions from 3118 experts welcome.
> This mandates that all proxies need to do LOST and the ecrit
> processing. For some types of deployments, I find it extremely
> unlikely that they would do this - instead they will make a small
> subset of the proxies do this and ensure the call goes thorough at
> least one of these. I think that describing that way might be far
> more realistic.
Good idea. I'll make that change.
> Is there any particular part of LLDP-MED we need to reference to get
> Section 9.1, point 4. not sure if you mean something specific by "URI
> of the device". Obviously would would not want this to be
> misinterpreted as the GRUU.
Okay, I'll clarify
> Cullen <with my individual contributor hat on>
> Ecrit mailing list
> [email protected]
Ecrit mailing list