>> 5) Statement that the string contains an FQDN, as stated for one case of >> the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is >> incomplete, as it needs to be accompanied by a normative reference to >> a document that specifies the format of internationalized domain >> names, and probably needs to also state which types of labels (e.g., >> A-label, U-label) are allowed. >> >> Every use of UTF8String in this draft needs to be checked, and most >> of them are likely to need some attention. The ongoing work in the >> precis WG may help with some of this, and I would suggest talking to >> the APP ADs, especially Pete Resnick (hi Pete) before embarking on >> significant work in this area in order to avoid wasted or duplicated >> efforts. > > OK, this last one bothers me a lot: you /seem /to be suggesting that we hold > up this draft to wait for the result of a WG which has yet to publish a > problem statement. I'm sure that that is not the case, but it sure sounds > like it. David can clarify if I'm wrong, but that's not what it sounds like to me. What it sounds like he's suggesting is that you talk with the precis people to see if things are OK, or if there's anything you should be doing differently. I'm adding the precis chairs to this message, and asking them to respond to this point. A tangential point, while I'm here: >> [4] Based on this text in 4.4.9: >> The use of this AVP is NOT RECOMMENDED; the AVPs defined by >> Korhonen, et al. [RFC5777] SHOULD be used instead. >> >> I would have expected RFC5777 to be a Normative Reference, not an >> Informative Reference. > > I don't care particularly, but I don't think that it's really necessary to > understand RFC 5777 to understand this document. It would seem odd, in general, if something that's a "MUST implement" or "SHOULD implement" weren't a normative reference. But I haven't (yet) looked at this particular case to see. Barry