RE: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Patrik Fältström [mailto:paf@cisco.com]
> Sent: Thursday, February 21, 2002 1:31 PM
> To: ietf-provreg@cafax.se; Jaap Akkerhuis; Ed Lewis;
> shollenbeck@verisign.com
> Cc: Ned Freed
> Subject: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt
> 
> 
> (1) CORE used but not defined.

CORE _is_ defined in section 1.1.  It can be removed completely if the IANA
considerations section is rewritten.

> (2) Reference in appx to IANA ports only.

I don't understand this comment.

> (3) 3.1[7] refers to transactional security without defining it.

Actually, it's transactional _integrity_, not security.  I can add a
sentence to explain what that means.

> (4) 3.4.2[2] talks about validity without defining it - in particular,
> preemption not discussed.

Would it be adequate to simply change "validity period" to "registration
period"?

> (5) 3.4.3[2] has 1 IP address with multiple name servers. Is 
> that really
> what you want?

Yes, per WG discussion it sure is.

> (6) 3.4.3 does not require the association of info with 
> registrars, but
> assumes it in [4].

Hmm, OK, so I need to add an explicit requirement to note that objects are
managed by a particular registrar/client?

> (7) 3.4.5 does not require the ability to do unapproved 
> transfer (such as
> if registrar is dead).

Actually, I think it's covered in 3.4.5-[4].  A dead registrar can't do
anything.

> (8) Section 4 (MUST not introduce limitations) is not really possible.

Sure it's possible.  The whole idea of this section is to help ensure that
the protocol specification doesn't get into defining implementation
specifics.  It might be possible to collapse the entire section into a
"don't limit implementation" statement, but I'd really like more guidance on
what needs to be changed here.

> (9) Internationalization requirements are (surprisingly) 
> reasonably OK.

Good!

> (10) Searchability requirements are VERY weak (by ID only) - that is
> probably how it should be.

Yes -- we're talking about requirements for a provisioning protocol, not a
search or lookup protocol.

> (11) The ID has NSI-specific registrations in it even though 
> its a WG doc,
> i.e. if the registrations has to be done, they should be in a separate
> document

The text says that what's in there aren't registrations to be done, they are
registrations that have been done in the past - which includes more than
just NSI-specific stuff.  Like I said, though, I'll gladly rewrite this
section.

> (12) The IANA considerations says:
> These assignments should be preserved as long as the 
> corresponding systems
> are operational.  Additional IANA services might be required 
> to support
> testing and deployment of protocol implementations.
> 
> 1/ how whould the IANA know to zap registrations?
>    (this partcular problem is removed if the NSI 
> registrations are removed)
> 2/ how is the IANA to know what to do to do the additiopnal 
> registrations?

Any needed additional registrations will have to be documented in
appropriate documents.  Perhaps that's all the IANA considerations section
should say.

Patrik, can you provide more specific instructions on what needs to be
changed, or are my suggestions above adequate?  I'd really like to make sure
that the next edit addresses these comments, but I need more detail to be
able to do that.

-Scott-