Subject: [Gen-art] Gen-ART review of draft-ietf-ccamp-te-node-cap-05

From: <[email-masked]>
Date: Wed, 30 May 2007 12:50:19 +0300

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call 
comments you may receive.

Document: draft-ietf-ccamp-te-node-cap-05 
Reviewer: Pasi Eronen
Review Date: 30 May 2007
IETF LC End Date: 06 June 2007
IESG Telechat date: (not known yet)

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:

1) Section 8.2 "[IS-IS-CAP] defines a new code point registry for
sub-TLVs carried in the ISIS CAPABILITY TLV". The current version of
[IS-IS-CAP] does not seem to define any new IANA-maintained
registries. This may be an bug in [IS-IS-CAP]?

2) Section 8.3: the bit numbers in this section don't match the bit
numbers in Sections 4.1/4.2.

3) As noted in the proto write-up, there's a normative downref (RFC
3784). This downref was not called out in the IETF last call message,
and it's not listed in the downref registry.

Best regards,
Pasi

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 30 May 2007 16:24:06 +0200

Hi Pasi,

Please see inline, 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> Envoyé : mercredi 30 mai 2007 11:50
> À : [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; LE ROUX Jean-Louis 
> RD-CORE-LAN
> Objet : Gen-ART review of draft-ietf-ccamp-te-node-cap-05 
> 
> I have been selected as the General Area Review Team 
> (Gen-ART) reviewer for this draft (for background on Gen-ART, 
> please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Summary: This draft is basically ready for publication, but 
> has nits that should be fixed before publication.
> 
> Comments:
> 
> 1) Section 8.2 "[IS-IS-CAP] defines a new code point registry 
> for sub-TLVs carried in the ISIS CAPABILITY TLV". The current 
> version of [IS-IS-CAP] does not seem to define any new 
> IANA-maintained registries. This may be an bug in [IS-IS-CAP]?

You are right this is a "bug" in [IS-IS-CAP] that has been fixed by IANA. IANA has actually defined a registry for sub-TLVs of the CAPABILITY TLV.
See sub-registry "Sub-TLVs for TLV 242" in http://www.iana.org/assignments/isis-tlv-codepoints

So we will remove the sentence "[IS-IS-CAP] defines a new code point registry for sub-TLVs carried in the ISIS CAPABILITY TLV"
and replace by "IANA has defined a registry for sub-TLVs of the IS-IS CAPABILITY TLV"

> 
> 2) Section 8.3: the bit numbers in this section don't match 
> the bit numbers in Sections 4.1/4.2.

OK, this will be fixed

> 
> 3) As noted in the proto write-up, there's a normative 
> downref (RFC 3784). This downref was not called out in the 
> IETF last call message, and it's not listed in the downref 
>registry.

OK, what shall we do to cover this point?

Best Regards,

JL

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 May 2007 16:51:59 -0400

Ross:

I think you have to issue a second Last Call to resolve this problem.

Russ

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 31 May 2007 10:22:31 +0100

Maybe someone could clarify the progress of the IS-IS RFCs from 
Informational to Standards Track.

It seems to me that this operation has been progressing for the longest 
time, and it is leaving everyone in a state of mild confusion about what 
they should be doing.

For example, if it is the intention that all IS-IS protocol RFCs will be 
Standards Track, then new I-Ds should have intended status of Standards 
Track. But that means that, until the old RFCs are upgraded, we 
automatically have a downref.

It seems to me that the downref process was not designed to handle this type 
of downref, and that we should just get on with things instead of enforcing 
this particular rule.

Adrian

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: <[email-masked]>
Cc: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, May 30, 2007 9:51 PM
Subject: Re: [Gen-art] RE: Gen-ART review of draft-ietf-ccamp-te-node-cap-05

---

From: Ross Callon <[email-masked]>
Date: Thu, 31 May 2007 10:52:07 -0400

At 10:22 AM 5/31/2007 +0100, Adrian Farrel wrote:
>It seems to me that the downref process was not designed to handle this 
>type of downref, and that we should just get on with things instead of 
>enforcing this particular rule.
>
>Adrian

Two issues here:  First of all, there is a group of seven IS-IS RFCs that are
in the process of being updated from Informational to Standards track. I
discussed this with Dave Ward, in his role as IS-IS co-chair, a month or
so ago, and we agreed that we needed updated IDs for minor editorial
reasons, such as updating references and changing the status indicated
on the first page of the draft. Thus my understanding is that we are
waiting on updates to the seven drafts.

Secondly: I think that the downref rules are actually quite silly, and are
an example (and definitely not the only example) of the IESG DOS'ing
itself. The rules state that we are supposed to mention downrefs in the
IETF last call. If we forget, then we get to repeat the last call or change
the type of reference. In fact, from the perspective of a vendor: No one
cares about whether a document is standards track or informational.
Whether it gets implemented depends upon customer demand, and
NOT on the status of the document. Also, in terms of people who have
products to build and/or networks to deploy, no one cares about
downrefs. Yes, there are some people who are not focused on building
products or deploying networks who will on rare occasion respond when
an IETF last call mentions a downref. However, we have lots of people
involved in the IETF who like to get bent out of shape about silly
details, and even these people don't bother to respond the vast majority
of the time when an IETF last call mentions a downref.

Thus personally I think that in the interest of making the IETF and more
efficient and more effective and practical standards organization, we
should change to the rules regarding downrefs to simply permit them,
and not require any special treatment for downrefs.

Ross

>----- Original Message ----- From: "Russ Housley" <[email-masked]>
>Cc: "LE ROUX Jean-Louis RD-CORE-LAN" 
><[email-masked]>; <[email-masked]>; 
><[email-masked]>; <[email-masked]>;