Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Oct 2010 14:06:07 -0500

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-ietf-isis-genapp-03.txt
Reviewer: Ben Campbell
Review Date: 05 Oct 2010
IESG Telechat date: 07 Oct 2010

Summary:

The draft is almost ready for publication as a proposed standard, but I have some concerns that I think should be addressed first.

Major issues:

-- This draft creates an "expansion" code point in an IANA registry, where the expansion registration requirements are weaker than those of the parent registry. This always makes me nervous, as it opens the window for end-runs around the registration requirements of the parent. 

In this particular instance, the parent registry policy is "expert review" while the proposed expansion registry policy is "specification required". This draft puts normative requirements on the content of the required specifications, and makes additional non-normative statements about the intended use of the GENINFO code point. This implies to me that the review process needs to do more than determine that sufficient specification exists. Rather, it needs to determine that the criteria in this draft are met by that specification. Therefore, I think that it would be appropriate for the GENINFO registry to use the "expert review" policy. 

Minor issues:

-- section 4.2, 2nd paragraph: "Where this is not possible, the two affected LSPs SHOULD be flooded as an atomic action"

Any reason that this is not a MUST, since it seems like the safety-net behavior for when the aforementioned SHOULD is not  possible to follow?

-- Section 4.3: "When information in the two GENINFO TLVs conflicts i.e there are different settings for a given attribute, the procedure used to choose which copy shall be used is undefined."

Should their be normative requirement not to create this undefined condition in the first place?

-- Security Considerations:

This seems too lightweight. Is it impossible for GENINFO applications to include sensitive information? Are there no security guidelines that should apply to GENINFO application specifications?

Even if the answer is that the underlying IS-IS protocol provides sufficient security for any reasonable use of the GENINFO code point, it would be worth saying that explicitly.

Nits/editorial comments:

-- section 2

Please expand IS-IS and PDU on first mention.

-- section 6, last paragraph:

Expected/desired by whom?

-- Outdated reference for draft-ietf-isis-mi

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 6 Oct 2010 05:55:42 -0700

Ben -

Thanx for the review.
Inline.

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, October 05, 2010 12:06 PM
> To: [email-masked]; General Area Review
Team
> Cc: The IETF
> Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
> 
> The draft is almost ready for publication as a proposed standard, but
I
> have some concerns that I think should be addressed first.
> 
> 
> Major issues:
> 
> -- This draft creates an "expansion" code point in an IANA registry,
> where the expansion registration requirements are weaker than those of
> the parent registry. This always makes me nervous, as it opens the
> window for end-runs around the registration requirements of the
parent.
> 
> In this particular instance, the parent registry policy is "expert
> review" while the proposed expansion registry policy is "specification
> required". This draft puts normative requirements on the content of
the
> required specifications, and makes additional non-normative statements
> about the intended use of the GENINFO code point. This implies to me
> that the review process needs to do more than determine that
sufficient
> specification exists. Rather, it needs to determine that the criteria
> in this draft are met by that specification. Therefore, I think that
it
> would be appropriate for the GENINFO registry to use the "expert
> review" policy.

>From RFC 5226:

"Specification Required - Values and their meanings must be
            documented in a permanent and readily available public
            specification, in sufficient detail so that interoperability
            between independent implementations is possible.  When used,
            Specification Required also implies use of a Designated
            Expert, who will review the public specification..."

We deliberately chose "Specification Required" because:

a)It requires a public specification
b)It allows the public specification to be other than an RFC
c)It requires expert review

> 
> Minor issues:
> 
> -- section 4.2, 2nd paragraph: "Where this is not possible, the two
> affected LSPs SHOULD be flooded as an atomic action"
> 
> Any reason that this is not a MUST, since it seems like the safety-net
> behavior for when the aforementioned SHOULD is not  possible to
follow?

It is a recommended behavior. If an implementation does not do this it
does not create an interoperability issue - but it may create
sub-optimal behavior. 

> -- Section 4.3: "When information in the two GENINFO TLVs conflicts
i.e
> there are different settings for a given attribute, the procedure used
> to choose which copy shall be used is undefined."
> 

If the revised version of a GENINFO TLV is sent in an LSP with a
different number from the previous version there can be transient
windows where other systems have two copies of information regarding the
same application. This may be unavoidable. For completeness we specify
that the choice of what to do in such transient situations is
implementation specific (undefined). This section does specify ways to
minimize the occurrence/duration of such transient periods.

> This seems too lightweight. Is it impossible for GENINFO applications
> to include sensitive information? Are there no security guidelines
that
> should apply to GENINFO application specifications?

We have no way of knowing what type of information might be advertised
by a given application - and we are not limiting what may be advertised.
Clearly the public document which specifies the application would need
to address the security issues it introduces. We cannot do that here.

> 
> Even if the answer is that the underlying IS-IS protocol provides
> sufficient security for any reasonable use of the GENINFO code point,
> it would be worth saying that explicitly.
> 
> Nits/editorial comments:
> 
> -- section 2
> 

OK

> Expected/desired by whom?

Well, at least by the authors. :-)

> -- Outdated reference for draft-ietf-isis-mi

It was current at the time the draft was written.

   Les

---

From: Ben Campbell <[email-masked]>
Date: Wed, 6 Oct 2010 09:10:25 -0500

Thanks for the quick response. Comments inline:

> c)It requires expert review

Completing the sentence in your quote: "who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations."

My understanding of "Specification Required" is that the expert review is merely to ensure that the documentation is sufficiently complete and readable to implement in an interoperable way. That review is not intended to ensure compliance to other criteria specified in the draft.

However, the draft includes some specific criteria for GENINFO applications. If you want the reviewer to enforce those criteria, then I think you need at least "Expert Review". OTOH, in RFC5226, the "expert review" policy has less to say about the required level of documentation, so the draft might require some more meat in that area.

I note that while RFC3563, which established the IS-IS TLV Codepoint registry, says "Expert Review", the review criteria is pretty much equivalent to "standards action". I'm guessing the only reason it was not "standards action" was to allow ISO/IEC JTC1/SC6 to submit specifications, which are to be held to the same standard as a standards-track RFC, but do not actually get published as such. So for practical purposes, the proposed policy for GENINFO is significantly weaker than for the parent registry--more so than one might think from just looking at the registry itself.

> does not create an interoperability issue - but it may create

Okay.

> minimize the occurrence/duration of such transient periods.

Does leaving this undefined cause interop issues? If not, then no problem.

> to address the security issues it introduces. We cannot do that here.

Since the registration policy is not at least "RFC Required", there's no explicit requirement that the public document actually do this. If you wish to require them to do it, you will need to state something to that effect. (See previous comment about whether the registration policy actually enforces that sort of criteria.)

> Well, at least by the authors. :-)

Okay :-) I guess, I meant to say that, if this expectation was a matter of WG concensus, you could state it more strongly, as in "The IS-IS working group expected..."

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 6 Oct 2010 08:14:44 -0700

Ben -

> Sent: Wednesday, October 06, 2010 7:10 AM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; General Area Review
> Team; The IETF
> Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-
> 03.txt
> 
> Completing the sentence in your quote: "who will review the public
> specification and evaluate whether it is sufficiently clear to allow
> interoperable implementations."
> 
> My understanding of "Specification Required" is that the expert review
> is merely to ensure that the documentation is sufficiently complete
and
> readable to implement in an interoperable way. That review is not
> intended to ensure compliance to other criteria specified in the
draft.
> 
> However, the draft includes some specific criteria for GENINFO
> applications. If you want the reviewer to enforce those criteria, then
> I think you need at least "Expert Review". OTOH, in RFC5226, the
> "expert review" policy has less to say about the required level of
> documentation, so the draft might require some more meat in that area.
> 

This is a bit distressing - because you are suggesting that RFC 5226
doesn't define a category which is appropriate for our usage - which
means we have to try to define a unique policy. I am not quite sure how
to do that with sufficient authority and minimal controversy.

My understanding is that RFC 5226 is specific to IANA considerations -
so we have attempted to define a clear policy as to how the review of
code point assignments is done.

Beyond that, it seems clear that a given Application specification could
specify behavior that might be seen as undesirable e.g. it could specify
some extremely high rate of updates. Given that we allow application
specification to be defined in public documents from a variety of
sources, I don't see how we could define an enforceable review policy
for the application specifications. It is at the IANA codepoint
allocation that we have control - and certainly it seems within the
purview of an expert to say "I think your specification is flawed and I
won't approve the allocation of codepoints until the issues of concern
are addressed".

> I note that while RFC3563, which established the IS-IS TLV Codepoint
> registry, says "Expert Review", the review criteria is pretty much
> equivalent to "standards action". I'm guessing the only reason it was
> not "standards action" was to allow ISO/IEC JTC1/SC6 to submit
> specifications, which are to be held to the same standard as a
> standards-track RFC, but do not actually get published as such. So for
> practical purposes, the proposed policy for GENINFO is significantly
> weaker than for the parent registry--more so than one might think from
> just looking at the registry itself.

I am not clear on why "Expert Review" is seen as a stronger review
criteria than "Specification Required" - which includes expert review as
well as a requirement for a public specification.

> Does leaving this undefined cause interop issues? If not, then no

There is no alternative. It is not possible to determine in a reliable
way which copy is "newer".

> Since the registration policy is not at least "RFC Required", there's
> no explicit requirement that the public document actually do this. If
> you wish to require them to do it, you will need to state something to
> that effect. (See previous comment about whether the registration
> policy actually enforces that sort of criteria.)

I appreciate your point - but I don't see how we have the authority to
place a requirement on a document developed in another standards body.

> Okay :-) I guess, I meant to say that, if this expectation was a
matter
> of WG concensus, you could state it more strongly, as in "The IS-IS
> working group expected..."

I don't think we currently have WG consensus on this point.

   Les

---

From: Ben Campbell <[email-masked]>
Date: Wed, 6 Oct 2010 10:55:12 -0500

On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote:

[...]

> won't approve the allocation of codepoints until the issues of concern

Yes, both "specification required" and "expert review" involve expert review. But they have significant differences in the scope of the review. "Specification required" means that the expert should review to make sure the specification is clear enough to be implemented in an interoperable fashion. It doesn't in any way indicate that the expert thinks the code point is "good", or that it conforms to the purpose of the registry. Certainly, the expert could offer advise on issues, but the registrant would not be under any obligation to follow the advise.

"Expert Review" means that the expert should review a registration to make sure that it conforms to the criteria set forth in the document that defined the registry. I really think that is what you are looking for, particularly from your last sentence above about the expert being able to block allocation of a flawed code point.

For example, RFC 3563 calls out "Expert Review", and sets a number of criteria, one of which is the assertion that registrations require standards actions, or that they require publications from  ISO/IEC JTC1/SC6 that meant the normal requirements for an RFC.

In your case, I think you need Expert Review, with criteria along the lines that registrants must meet the requirements of "specification required", that it must describe its expected rate of updates (and that this not be excessive), that it must address any security considerations, etc.

> well as a requirement for a public specification.

Actually, "expert review" doesn't have to be stronger than specification required. But it can be. It's all a matter of how you define the review criteria. The difference is, in "expert review" you get to define the criteria. In "specification required", the criteria is already defined, and fairly limited.

RFC3563 has has quite strict criteria, thus my comment about it being "stronger". For all practical purposes, the policy for RFC 3563 is "standards action" with some very specific exceptions.

[...]

> way which copy is "newer".

Okay

[...]

> place a requirement on a document developed in another standards body.

You can set criteria for the codepoint allocation, though. Requiring the specification of a code point to address security seems to be a reasonable criteria.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 6 Oct 2010 09:08:23 -0700

Ben -

The points you make below make sense to me - but I am not sure how we
get the stronger review process associated w "Expert Review" and at the
same time require that some public document exist for each application.
Are you saying that we can require both? I actually thought that was the
intent of "Specification Required" - but your comments suggest
otherwise.

I really wish RFC 5226 addressed this more robustly...

   Les

> Sent: Wednesday, October 06, 2010 8:55 AM
> > purview of an expert to say "I think your specification is flawed
and
> Yes, both "specification required" and "expert review" involve expert
> review. But they have significant differences in the scope of the
> review. "Specification required" means that the expert should review
to
> make sure the specification is clear enough to be implemented in an
> interoperable fashion. It doesn't in any way indicate that the expert
> thinks the code point is "good", or that it conforms to the purpose of
> the registry. Certainly, the expert could offer advise on issues, but
> the registrant would not be under any obligation to follow the advise.
> 
> "Expert Review" means that the expert should review a registration to
> make sure that it conforms to the criteria set forth in the document
> that defined the registry. I really think that is what you are looking
> for, particularly from your last sentence above about the expert being
> able to block allocation of a flawed code point.
> 
> For example, RFC 3563 calls out "Expert Review", and sets a number of
> criteria, one of which is the assertion that registrations require
> standards actions, or that they require publications from  ISO/IEC
> JTC1/SC6 that meant the normal requirements for an RFC.
> 
> In your case, I think you need Expert Review, with criteria along the
> lines that registrants must meet the requirements of "specification
> required", that it must describe its expected rate of updates (and
that
> this not be excessive), that it must address any security
> considerations, etc.
> 
> >
> > criteria than "Specification Required" - which includes expert
review
> as
> Actually, "expert review" doesn't have to be stronger than
> specification required. But it can be. It's all a matter of how you
> define the review criteria. The difference is, in "expert review" you
> get to define the criteria. In "specification required", the criteria
> is already defined, and fairly limited.
> 
> RFC3563 has has quite strict criteria, thus my comment about it being
> "stronger". For all practical purposes, the policy for RFC 3563 is
> "standards action" with some very specific exceptions.
> 
> [...]
> 
> >>>
> >>> windows where other systems have two copies of information
> regarding
> >> the
> >>> implementation specific (undefined). This section does specify
ways
> >> to
> You can set criteria for the codepoint allocation, though. Requiring
> the specification of a code point to address security seems to be a
> reasonable criteria.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 6 Oct 2010 16:33:46 -0500

> I really wish RFC 5226 addressed this more robustly...

Don't take the choices in RFC 5226 as the only thing you can do--there's room for "tweaking" them to your needs.  It seems like you are really looking for the union of "Expert Review" and "Specification Required". 
 
It's easier to start from "Expert Review" since it is the more flexible of the two policies ( in that it explicitly states that the document that establishes the registry will contain the criteria for the review.)  It's perfectly okay to have that criteria include something to the effect of "The code point must be defined in a publicly available document that substantially meets the requirements of the 'Specification Required' policy in RFC 5226."