Subject: [Mipshop] AD review of draft-ietf-mipshop-mos-dns-discovery

From: Jari Arkko <[email-masked]>
Date: Fri, 17 Oct 2008 19:48:40 +0300

I have reviewed this draft, and found a small number of issues that you 
should fix before moving forward. I also need to talk to some further 
NAPTR experts, I have concerns about the IANA registration (more on that 
later). But please fix these issues first.

Technical:

Change the title to include "IEEE 802.21 mobility services", per 
suggestions from reviewers.

>    The services relevant for the task of transport protocol selection
>    are those with NAPTR service fields with values "IS+M2X" for IS
>    service, "ES+M2X" for the ES service, "CS+M2X" for the CS service,
>    where X is a letter that corresponds to a transport protocol
>    supported by the domain.

Why are the secure versions not listed here? Perhaps you could say ".... 
with values "ID+M2X" for ID is the service identifier defined in the 
previous section and X is a ..."

> This specification defines M2U for UDP, M2T for TCP and M2S for SCTP.

I would recommend removing SCTP, because -mstp-solution does not support 
it. As I recall, 802.21 does not support it either, (though some 
references to SCTP remain in the text; maybe that has been an error).

> New Service Fields are to be added via Standards Action as defined in 
> [RFC5226]. New entries to the table, specifying additional transport 
> protocols for the existing Service Fields may be requested from IANA 
> on a First Come First Served' basis [RFC5226].

IESG Approval makes more sense for this, IMO. Its a rare event, and IESG 
approval is actually easier for most situations than an expert review, 
because a draft that comes through the IETF does not need to be sent 
separately to an expert. And I agree with Vijay's comments on list about 
one table having a too complicated IANA rule. But this points relates to 
the NAPTR worry that I'm investigating; I need to come back on that.

Editorial:

In the abstract (or perhaps even in the title, see above), the first 
time you say "mobility services", I would recommend you say "IEEE 802.21 
mobility services". This makes the scope of the document much clearer.

Please open the acronym "MN" in the abstract, and give the reference as 
"IEEE 802.21".

References: please renumber. Having reference [1] after all the others 
looks a bit silly. Same does [2] (an RFC) followed by [RFC4033], also an 
RFC.

>    Service Management" service messages, i.e., MIH registration, MIH
Missing or extra "

Jari

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Oct 2008 07:47:27 +0300

A follow-up on the NAPTR issues. I had some misgivings about the way 
NAPTR is used here, and after a very quick discussion with some DNS 
experts, it seems that I have to ask this:

1) Why aren't you using S-NAPTR (RFC 3958)?

2) If you define a direct DDDS definition on top of NAPTR, you should 
really do everything that is required in RFC 3401 Section 4, and I don't 
think you are.

3) I do not understand the way that the IANA registrations have been 
made. Since several services may exist in the same domain, how do we 
ensure that MIPSHOP services and some other services do not collide? 
Note that with S-NAPTR this would have been easy.

I would recommend that the authors use RFC 3958 instead and change the 
relevant parts of the specification to switch to that, including the 
IANA registration.

But I have to confess that I am not at all a NAPTR expert myself. I 
looked at the RFCs in question for the first time few days ago. If you 
think what I am suggesting is wrong, please say so and we can talk about 
it. If you don't think you can do the above change on your own, also ask 
for help -- I can arrange experts that you could talk to about it.

Jari