Subject: RE: DHCP Packets with Option 82 from Trusted Circuit

From: "Mark Llacuna" <[email-masked]>
Date: Fri, 18 May 2001 15:05:04 -0700

: 
: > I agree.
: 
: So are you going to write it up?   :')
: 
: 			       _MelloN_
:

I knew you were gonna ask.

Hmmm... let me discuss this with the rest
of my team.

Mark

---

From: [email-masked]
Date: Mon, 21 May 2001 22:32:47 -0700

> -----Original Message-----
> From: Mark Llacuna [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 7:48
> To: DHCPv4 discussion list
> Subject: DHCP Packets with Option 82 from Trusted Circuit
> 
> Hello Everyone, 
> Section 2.1 of RFC 3046 says: 
>   A trusted circuit may contain a trusted downstream (closer 
> to client) 
>   network element (bridge) between the relay agent and the 
> client that 
>   MAY add a relay agent option but not set the giaddr field.  In this 
>   case, the relay agent does NOT add a "second" relay agent 
> option, but 
>   forwards the DHCP packet per normal DHCP relay agent operations, 
>   setting the giaddr field as it deems appropriate. 

> From an email exchange with the author of the RFC, it was 
> clarified that 
> the keywords "does NOT" in the last statement, above, should be 
> interpreted as "MUST NOT".

I think the RFC is correct in not using "MUST NOT," and implementers should
not interpret it as "MUST NOT."  The RFC simply gives an example of a policy
that network operators might implement.  They might implement another
policy.  The protocol does not care, and network operator policies are not a
matter for standardization.

Here's an example of a policy that operators might implement:

The DSLAM uses one suboption for its ID (say, Remote-ID)
The relay-agent uses the other suboption (say, Circuit-ID)

Each agent can deal with his own piece of the pie.  This is completely
standard, though not necessarily all implementations are capable of it.

---

From: "Mark Llacuna" <[email-masked]>
Date: Tue, 22 May 2001 08:34:55 -0700

: 
: I think the RFC is correct in not using "MUST NOT," and 
: implementers should
: not interpret it as "MUST NOT."  The RFC simply gives an 
: example of a policy
: that network operators might implement.  They might implement another
: policy.  The protocol does not care, and network operator 
: policies are not a
: matter for standardization.

>From my perspective, that section of the RFC is NOT very
clear in its intention, and your interpretation of it could
be one of many, if not the only correct one.

As I have mentioned, I asked Michael Patrick what "does NOT"
meant in that context. In an email he replied that it meant
"MUST NOT", which is contrary to what you think its
interpretation should be.

Aside from that, it's not clear what "a "second" relay agent
option" means. Why is "second" quoted? Does it refer to a
relay agent option encoded next to another relay agent option?
Can a relay agent option encapsulated in another (which is not
dealt in the RFC) be also considered a "second" option?  

If indeed the RFC only meant the section as "an example of a
policy that network operators might implement", I think it
should also state this intention to avoid ambiguities. 

: 
: Here's an example of a policy that operators might implement:
: 
: The DSLAM uses one suboption for its ID (say, Remote-ID)
: The relay-agent uses the other suboption (say, Circuit-ID)
: 
: Each agent can deal with his own piece of the pie.  This is completely
: standard, though not necessarily all implementations are 
: capable of it.
: 

What if both the DSLAM and Relay Agent need to be configured
or have to use the same suboption?

Mark