Subject: [dhcwg] Call for review of draft-ietf-geopriv-lis-discovery

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Feb 2010 14:49:17 -0700

We've reviewed this document before, but there have been a number of substantive changes, and so it seems that there should be another review by the working group.   We got some good feedback on this draft last time we reviewed it, so I'm hoping some of the folks who looked at it then can take another look now.

Easy access: https://datatracker.ietf.org/doc/draft-ietf-geopriv-lis-discovery/

Thanks,

Ted

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Feb 2010 13:55:58 +0800

I suspect that this request got lost in the lively discussions of the last week.

Has anyone got a few minutes to read through and comment briefly on Sections 3.1, 3.2 and 3.3?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Lemon
> Sent: Thursday, 18 February 2010 8:49 AM
> To: DHC WG
> Subject: [dhcwg] Call for review of draft-ietf-geopriv-lis-discovery
> 
> We've reviewed this document before, but there have been a number of
> substantive changes, and so it seems that there should be another
> review by the working group.   We got some good feedback on this draft
> last time we reviewed it, so I'm hoping some of the folks who looked at
> it then can take another look now.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Feb 2010 10:34:31 -0800

> on Sections 3.1, 3.2 and 3.3?

I think I'd like to see an example of just the domain name encoding in
section 3.1, "| 7 | example | 3 | com | 0 |" or similar.  Then in
section 3.2 and 3.3, where 3.2 is describing the contents as
"| s1 | s2 | s3 | ...", 3.3 is different in describing the field
(which we understand to be formatted the same) as "Access Network
Domain Name" and refers back to 3.1.

I think I'd like to see section 3.2 made to be consistent with 3.3,
document the single-octet TBD code and length, then refer to 3.1 for
the format.  Note that currently the ASCII art doesn't make it clear
the code and length are 8 bits, although hopefully a DHCPv4
implementer knows this.  Next to the DHCPv6 option it may confuse some
of the more easily confused however.  It may be better to adopt the
same (modern/DHCPv6) look and feel to the ASCII art for both.

Note that the format you've chosen is the DHCPv6 standard on domain
name formatting (it is mentioned in RFC 3315), with the exception of
the limit of one name (which also implies no compression tags which
DHCPv4 might otherwise use).  I don't know if it would simplify your
job of documenting the format for both options to simply refer to the
RFC 3315 format for domain names and provide an example, but I wanted
to mention it.  The existing text you have is possibly more complete
and useful than even RFC 3315's brief definition, and I understand the
value of directly referencing 1035 instead of recursive-referencing
through 3315.

I don't know if I understand the reason why the option does not
convey a URI directly rather than asking the client to engage in
U-NAPTR over a domain name, but as I'm not participating in geopriv I
assume that's a long discussion you've already had (and I think this
draft first came to us describing multiple URI's?).  I do know that
DHCPv4 and DHCPv6 servers today probably cannot engage in U-NAPTR on
the client's behalf, at least I am not aware of implementations that
do.

I think these comments are editorial in nature, the overall structure
and use of DHCP is completely adoptable today.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 25 Feb 2010 07:42:28 +0800

Thanks David,

I'll try to limit the impact of the changes, but these are good suggestions.

Changes:

 - Added example (example.com.) to Sec3.1
 - Changed v4 option description to match the format of the v6 option (pictures and text).

At this stage, referencing 3315 seems like more work than it's worth, and I'd rather not make such changes at this stage.  BTW, I can't take credit, the text was appropriated from RFC 5223 ;)

Some day, ask me about the U-NAPTR thing, it's a long and boring tale.

--Martin

> From: David W. Hankins [mailto:[email-masked]]
> Sent: Thursday, 25 February 2010 5:35 AM
> To: Thomson, Martin
> Cc: DHC WG
> Subject: Re: [dhcwg] Call for review of draft-ietf-geopriv-lis-
> discovery
>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Feb 2010 16:30:42 -0800

> Thanks David,

Happy to help.

> At this stage, referencing 3315 seems like more work than it's worth,
> and I'd rather not make such changes at this stage.  BTW, I can't take
> credit, the text was appropriated from RFC 5223 ;)

Yes, I was really only mentioning that for completeness or contrast, I
think this is essentially the prerogative of the author - what you've
got is great!  I don't remember reviewing 5223, so I guess that's why
I don't recognize it.  I should seriously consider also stealing it as
a suggested boilerplate in the options-guideline draft.