![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> *enc* field is not familiar with DHC folks hm. Interesting. there are RFCs already using it, eg RFC3361. > [MoS-option-code] [len] [sub-option-code] [len1] [len1 bytes] [sub-option-code] [len2] [len2 bytes] ... > o MoS Suboption Code 1 = domain name > o MoS Suboption Code 2 = IPv4 address yes, this also works. Or, I could define two separate options, one carrying domain names, the other IP addresses .... - gabor ________________________________ From: ext Daniel Park [mailto:soohongp at gmail.com] Sent: Friday, October 05, 2007 8:25 PM To: Zuniga, Juan Carlos Cc: STDS-802-21 at listserv.ieee.org; mipshop at ietf.org Subject: Re: [Mipshop] IETF MIPSHOP MIH L3 transport - Internet draft (DHCPcomments) This is a couple of DHCP-comments (draft-bajko-mos-dhcp-options-00) as part of MoS discovery procedure. [1] As I pointed out at 802.21 meeting, AFAIC, *enc* field is not familiar with DHC folks. This is my real experience from DHC discussion long time ago regarding *draft-daniel-dhc-mihis-opt*. The option format described here is fairly hard to adopt. Sub-options are well understood by server implementors, so 'proper support' would not need any code changes. In bried, here is a proposed new format: [MoS-option-code] [len] [sub-option-code] [len1] [len1 bytes] [sub-option-code] [len2] [len2 bytes] ... o MoS Suboption Code 1 = domain name o MoS Suboption Code 2 = IPv4 address Equal to DHCPv6 option format (different length and format of options) This is immediately adoptable without code changes or requiring users to read RFCs, by what I assume would be all DHCP server software (it at least would be trivial for ours). For multiple encodings, *sub-option* approach would be sufficient. [2] In *draft-daniel-dhc-mihis-opt*, we did propose only IS use case not ES and CS cases. It is because I didn't see any applicable cases regarding ES and CS in conjunction with DHCP. I know this solution document is not about IS but about all 802.21 services (ES/CS/IS), but I am curious you are assuming DHCP server should have all ES and CS entities information ? I've quickly made some of DHCP comments. Further comments on this solution document will be forthcoming once carefully reading this document again. Anyhow, thanks for all of your effort on this document. Daniel Park [at] SAMSUNG Electronics. On 9/26/07, Zuniga, Juan Carlos <JuanCarlos.Zuniga at interdigital.com> wrote: Hello guys, As Gabor mentioned in his presentation last week in the 802.21 meeting, the MIPSHOP MIH Transport Design Team has just produced a first draft for the solution of the L3 transport of the 802.21 MIH protocol. Please take a look at the document and provide your comments on both IEEE 802.21 and IETF MIPSHOP lists so that we can move forward in having a final solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melia-mipshop-mstp-solution-00 .txt Best regards, Jc _______________________________________________ Mipshop mailing list Mipshop at ietf.org https://www1.ietf.org/mailman/listinfo/mipshop
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mipshop mailing list Mipshop at ietf.org https://www1.ietf.org/mailman/listinfo/mipshop