Thanks for your review, Brian. I too would be interested in seeing a response to Brian's question. Brian R, Adam, Richard?
Jari On Dec 13, 2013, at 2:38 PM, Brian E Carpenter <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-rosen-rph-reg-policy-01.txt > Reviewer: Brian Carpenter > Review Date: 2013-12-14 > IETF LC End Date: 2013-12-09 > IESG Telechat date: 2013-12-19 > > Summary: Ready with issues > -------- > > Comment: > -------- > > I have seen no response to my Last Call comments so this review has not > changed. > > This is a sipcore WG draft despite its file name. > > Major Issue: > ------------ > > "Experience > has suggested that a document that only defines a new namespace with > its priorities, and does not create new protocol semantics, should > not be a standards-track document." > > I have a couple of problems with this sentence. > > 1. It reads like a broad statement of IETF policy. Given that we have a > normative > document in this area (RFC 5226) and an IAB advisory document about > extensions in > general (RFC 6709), I don't think the statement is true in general, > regardless of > whether it's true in this particular case. > > 2. "Experience has suggested..." is a weak justification for a change in > policy, > even for these two specific registries. Actually, I can't possibly judge from > the draft whether the change is safe (the considerations for why it might be > safe or dangerous are in RFC 6709). > > I would be reassured by an evidence-based justification, along the lines of > > "Experience with the N namespaces and M resource-priorities defined since the > publication of RFC 4412, without creating new protocol semantics, has shown > that such definitions do not cause interoperability issues. Therefore > documents > that only define such namespaces and priorities do not need to be on the > standards > track." > > If that isn't true (i.e. there can be interoperability issues) we have a > bigger problem. > > Minor issue: > ------------ > > I believe the title, Abstract and Introduction should mention SIP for clarity. > > Nit: > ---- > > In the Abstract, s/ ti / to / > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
