Subject: Re: [Gen-art] Gen-ART review of draft-groves-megaco-pkgereg-02

From: Christian Groves <[email-masked]>
Date: Fri, 13 Mar 2009 16:54:00 +1100

Hello Peter and Cullen,

Peter, thanks for the comments. With regards to the major issue I would 
agree with Cullen's comments. In addition it's important to point out 
that the draft largely documents the process as it being implemented. 
The written description (pre this draft) doesn't actually match what is 
occurring. The draft also tries to set some review guidelines which 
again weren't documented. We have previously in the Megaco/H.248 work 
had cases where packages have been registered but basic things were 
missing or not well explained which have caused issues. By describing a 
review path we hope to pick these issues up before a package is fully 
registered.
 
Please see my comments below on the other issues marked [CNG]

Once we resolve the "recognised standards organisation" issue i'll 
provide an updated draft.

Regards, Christian

Cullen Jennings wrote:
>
> Christian, could you take a look at the minor issues & nits and submit 
> a draft to resolve theses - if some of them don't need to be changed, 
> just sort that on this email thread.
>
> Peter, on the topic of the Major issue...
>
> The existing procedures require the review to happen at IETF. Almost 
> all the work on this is actually happening at ITU right now so we are 
> trying to make it easier for the ITU folks get the approvals they need 
> done. We will select an expert reviewer that is closely involved with 
> the ITU folks working on this as they are much more aware of all the 
> ongoing work is and can catch conflicts, duplicated efforts etc.
>
> This should make it easier to get things approved than the current 
> process while at the same time helping improve the actual quality of 
> the review.
>
> Hope that helps.
>
> Cullen
>
> On Feb 23, 2009, at 11:50 AM, McCann Peter-A001034 wrote:
>
>> 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-groves-megaco-pkgereg-02
>> Reviewer: Peter J. McCann
>> Review Date: 23 February 2009
>> IETF LC End Date: 23 February 2009
>> IESG Telechat date: unknown
>>
>> Summary: Ready with nits, if the IESG wants to change the IANA
>> considerations for H.248.
>>
>> Major issues:
>>
>> This document inserts an expert review procedure in the allocation
>> policy for new H.248 packages/error codes/service change/profiles.
>> This is probably a good thing but I have not been following the
>> history of the H.248 effort so I'm not aware of any problems that
>> have occurred under the existing allocation policies.  The IESG
>> should weigh carefully whether the allocation policy really needs
>> changing.
>>
>>
>> Minor issues:
>>
>> In a couple of places the document gives special treatment to
>> "recognized standards bodies."  How does a standards body become
>> "recognized" by the IETF?  Should we specify that a liaison relationship
>> must be in place?
[CNG] Yes it may be good to add which bodies are recognized. Given that 
H.248/Megaco was developed jointly the people who came mainly from IETF 
thought "IETF Liaison relationship" and those from the ITU probably 
thought "Recognised Standards Development Organisation". I had a quick 
look at the IETF website and found: 
http://www.ietf.org/liaisonActivities.html is this the list of bodies 
who the IETF has a liaison relationship with?

The ITU-T also maintains a list of qualified Forums/Consortiums 
(http://www.itu.int/ITU-T/lists/qualified.aspx#forums). This seems to be 
a more comprehensive list of organisations (i.e. it includes national 
bodies). Could I had a pointer to this list in the draft?

>>
>> Section 4.2 states that a specification is required for review by
>> the designated expert, but it seems to allow that this specification
>> isn't publicly available.  Should there be a requirement at least for
>> public packages that the specification be public?
[CNG] I think this is really dependent on the rules of the standards 
organisation. The IETF is good that all documents are public but this 
doesn't apply to organisations such a MSF where the documents are 
available to the members but not the general public. So I don't think 
the draft can mandate that the package should be publicly available.
>>
>>
>> Nits/editorial comments:
>>
>> Section 1:
>> OLD:
>>   Given this situation, it is appropriate that the H.248/Package
>>   Package definition
>> NEW:
>>   Given this situation, it is appropriate that the H.248/Package
>>   definition
[CNG] OK
>>
>> Section 4.2:
>> OLD:
>>   2) The package requester shall provide a contact name, email and
>>   postal addresses for that contact shall be specified.
>> NEW:
>>   2) The package requester shall provide a contact name, and an email
>> and
>>   postal address for that contact shall be specified.
[CNG] OK
>>
>> OLD:
>>   provided available for review
>> NEW:
>>   provided and available for review
[CNG] OK
>>
>> OLD:
>>   5) Package names are allocated on a first come-first served if all
>>   other conditions are met.
>> NEW:
>>   5) Package names are allocated on a first come-first served basis if
>> all
>>   other conditions are met.
[CNG] OK
>>
>> Section 5.1:
>> OLD:
>>   shall forward to received information
>> NEW:
>>   shall forward the received information
[CNG] OK
>>
>> Section 5.2:
>> OLD:
>>   On the request for an Error Code registration, the IANA shall forward
>>   to received information (i.e. the Error Code text (Specification
>>   required) to the IESG appointed expert for review (See section 4.3).
>> NEW:
>>   On the request for an Error Code registration, the IANA shall forward
>>   the received information (i.e. the Error Code text and required
>> specification)
>>   to the IESG appointed expert for review (See section 4.3).
[CNG] OK
>>
>> Section 5.3:
>> OLD:
>>   On the request for an Error Code registration, the IANA shall forward
>>   to received information (i.e. the Service Change Reason text
>>   (Specification required) to the IESG appointed expert for review (See
>>   section 4.4).
>> NEW:
>>   On the request for an Service Change Reason registration, the IANA
>> shall forward
>>   the received information (i.e. the Service Change Reason text and
>>   required specification) to the IESG appointed expert for review (See
>>   section 4.4).
[CNG] OK

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 13 Mar 2009 11:19:46 -0400

Hi, Christian,

I am fine on your and Cullen's explanation on the major issue.  
It sounds like expert review is the right policy here.  By choosing
an expert closely affiliated with the ITU study group I guess we
are ceding some of the change control to them, which matches what
has been happening with the rest of the H.248 standards.

On the question of "recognized standards organization", I really
wonder if we can do without this distinction.  It seems like the
rules given in the draft mainly allow shorter codes to be registered
by these organizations.  Would it really harm the world for an 
individual to register a package with a short name?  I can imagine
that some packages may become important even when not developed by
a "recognized standards organization".  Given the review that needs 
to take place, we could easily guard against squatting or spamming
behaviors.

On the question of publicly available specifications, personally I
would like to see this required of public packages.  I don't think
it's fair for someone to use the IETF process for registering such
a package without disclosing enough information for anyone to produce
an interoperable implementation.  The situation with H.248 right
now is that I can go to the ITU website and download a copy, which
I think removed some of the qualms IETF may have had about turning
over change control from MEGACO to ITU.  I wouldn't want to see 
H.248 turned into a proprietary protocol through the extension 
mechanisms.

-Pete

Christian Groves wrote:
> Hello Peter and Cullen,
> 
> Peter, thanks for the comments. With regards to the major issue I
> would agree with Cullen's comments. In addition it's important to
> point out that the draft largely documents the process as it being
> implemented.   
> The written description (pre this draft) doesn't actually match what
> is occurring. The draft also tries to set some review guidelines
> which again weren't documented. We have previously in the
> Megaco/H.248 work had cases where packages have been registered but
> basic things were missing or not well explained which have caused
> issues. By describing a review path we hope to pick these issues up
> before a package is fully registered.      
> 
>> Christian, could you take a look at the minor issues & nits and
>> submit a draft to resolve theses - if some of them don't need to be
>> changed, just sort that on this email thread.
>> 
>> trying to make it easier for the ITU folks get the approvals they
>> need done. We will select an expert reviewer that is closely
>> involved with the ITU folks working on this as they are much more
>> aware of all the ongoing work is and can catch conflicts, duplicated
>> efforts etc. 
>> 
>>> I have been selected as the General Area Review Team (Gen-ART)
>>> reviewer for this draft (for background on Gen-ART, please see
>>> Please resolve these comments along with any other Last Call
>>> comments you may receive. 
>>> 
>>> "recognized" by the IETF?  Should we specify that a liaison
>>> relationship must be in place?
> [CNG] Yes it may be good to add which bodies are recognized. Given
> that H.248/Megaco was developed jointly the people who came mainly
> from IETF thought "IETF Liaison relationship" and those from the ITU
> probably thought "Recognised Standards Development Organisation". I
> had a quick look at the IETF website and found:    
> (http://www.itu.int/ITU-T/lists/qualified.aspx#forums). This seems to
> be a more comprehensive list of organisations (i.e. it includes
> national bodies). Could I had a pointer to this list in the draft?   
> 
> 
> 
> 
>>> 
>>> isn't publicly available.  Should there be a requirement at least
>>> for public packages that the specification be public?
>>> Package definition NEW:
>>>   2) The package requester shall provide a contact name, and an
>>>   email and postal address for that contact shall be specified.
>>> [CNG] OK 
>>> 
>>> OLD:
>>>   5) Package names are allocated on a first come-first served if
>>> all   other conditions are met. NEW:
>>>   5) Package names are allocated on a first come-first served basis
>>> if all
>>>   On the request for an Error Code registration, the IANA shall
>>>   forward to received information (i.e. the Error Code text
>>>   (Specification required) to the IESG appointed expert for review
>>>   (See section 4.3). NEW: On the request for an Error Code
>>>   registration, the IANA shall forward the received information
>>>   (i.e. the Error Code text and required specification) to the IESG
>>> appointed expert for review (See section 4.3). [CNG] OK 
>>> 
>>> Section 5.3:
>>> OLD:
>>>   On the request for an Error Code registration, the IANA shall
>>>   forward to received information (i.e. the Service Change Reason
>>>   text (Specification required) to the IESG appointed expert for
>>> review (See   section 4.4). NEW:
>>>   On the request for an Service Change Reason registration, the
>>>   IANA shall forward the received information (i.e. the Service
>>>   Change Reason text and required specification) to the IESG
>>>   appointed expert for review (See section 4.4).
> [CNG] OK

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Mar 2009 07:38:26 -0600

On Mar 12, 2009, at 11:54 PM, Christian Groves wrote:

> had a quick look at the IETF website and found:http://www.ietf.org/liaisonActivities.html 
>  is this the list of bodies who the IETF has a liaison relationship  
> with?

"Recognized SDO" is a somewhat vague term at IETF - basically the IAB  
can determine who is or is not one but there is no question that  
someone groups like ITU-T, ATIS, ETSI, 3GPP, W3C,  etc are recognized  
SDOs - it gets more dice when you move to something XSF. I'm fine with  
this level of vagueness as it leaves things flexible. Keep in mind we  
are discussing the length of a small string that occurs in a binary  
protocol over the wire - I have a hard time getting worked up my the  
total impact of this one way or the other.

>
>
> The ITU-T also maintains a list of qualified Forums/Consortiums (http://www.itu.int/ITU-T/lists/qualified.aspx#forums 
> ). This seems to be a more comprehensive list of organisations (i.e.  
> it includes national bodies). Could I had a pointer to this list in  
> the draft?
>

Uh, the ITU list is pretty irrelevant for this IETF doc. I will note  
that as far as I understand ITU does *not* recognize the IETF as a SDO  
but talks to ISOC (which is more definitely not the IETF these days)  
as a sector member.

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Mar 2009 16:43:14 +1100

Hello Cullen,

The actual encoding issue of the "string" arises only in the text 
version of the protocol :).

I think that when the original specification of packages was done people 
wanted to distinguish between packages that SDO groups produced and 
those that a single company produced. I guess a similar distinction 
between working group ietf drafts and individual submission drafts. It 
says something to people.

With regards to referencing an ITU list by the IETF I don't really 
consider this a political issue. I've quite happily added references to 
IETF documents and IANA lists. If someone has compiled a useful list 
that can be referenced without me having to re-invent the wheel then I'm 
happy do this.

However in conclusion I'm more than happy to leave "Recognised SDO" 
vague as this is what has been specified for the last 8 years and this 
aspect hasn't caused any problems to date.

Regards, Christian

Cullen Jennings wrote:
>> had a quick look at the IETF website and 
>> found:http://www.ietf.org/liaisonActivities.html is this the list of 
>> bodies who the IETF has a liaison relationship with?
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Mar 2009 19:58:45 +1100

Hello Peter,

Please see my comments below, marked [CNG].

Regards, Christian

> has been happening with the rest of the H.248 standards.
[CNG] I don't see the expert issue is one of affiliation or control it 
just should be someone who is activity following or contributing to the 
work. I would expect that that person would have to follow both the IETF 
and the ITU.
> to take place, we could easily guard against squatting or spamming
[CNG] I've addressed this point more in response to Cullen email. The 
original intention behind the split registry was that packages defined 
by SDOs would be perceived differently to private packages.
> H.248 turned into a proprietary protocol through the extension 
[CNG] We've had the distinction between public and private packages 
since the first Megaco/H.248 RFC/Recommendation and haven't had any 
issues with this aspect thus far. I personally think that standards 
should be made available to everyone but the reality is that there are 
SDOs/Fora where documents are only available to members. I think this 
availability is a general issue and not just applicable the Megaco/H.248 
work.
I think that it is a good thing that they may want to use Megaco/H.248, 
if they want to add packages in addition to what is already defined then 
for me this is OK. If those packages are applicable to the wider 
community then this is a comment that I think the IESG appointed expert 
can make and encourage the organisation to make it more widely 
available. This has occurred with 3GPP where they have proposed a 3GPP 
specific function but based on feedback have let the ITU produce a more 
general widely available solution. Another case was the MSF which was 
looking at standardising their own packages which would have been made 
available only to there members. On review and feedback it was pointed 
out that the packages in instances were incorrect and in other instances 
the packages were incorporated into ITU/ETSI documents.
So in short, to this date we haven't had the "proprietary protocol" 
issue and I don't think that the people/companies currently involved in 
the Megaco/H.248 standard would desire that this would happen.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 27 Mar 2009 13:15:30 -0400

Hi, Christian,

Sorry for the delay in responding.

I am happy to let the IESG make a decision on whether or not
to make a distinction for "recognized" SDOs, and for availability
of specification.  I just wanted to make one point that may have
been glossed over: there is a distinction made between "public"
packages and "private" packages; they have different number spaces
for the binary ID.  Would it be too much to ask that if a specification
is not publicly available at a stable URL, then the package must
be registered in the "private" space?

-Pete

Christian Groves wrote:
>> an expert closely affiliated with the ITU study group I guess we are
>> ceding some of the change control to them, which matches what has
>> been happening with the rest of the H.248 standards.
>> 
> [CNG] I don't see the expert issue is one of affiliation or control
> it just should be someone who is activity following or contributing
> to the work. I would expect that that person would have to follow
> both the IETF and the ITU.   
>> that some packages may become important even when not developed by a
>> "recognized standards organization".  Given the review that needs to
>> take place, we could easily guard against squatting or spamming
>> behaviors. 
>> 
> original intention behind the split registry was that packages
> defined by SDOs would be perceived differently to private packages.  
>> it's fair for someone to use the IETF process for registering such a
>> package without disclosing enough information for anyone to produce
>> an interoperable implementation.  The situation with H.248 right now
>> is that I can go to the ITU website and download a copy, which I
>> think removed some of the qualms IETF may have had about turning
> should be made available to everyone but the reality is that there
> are SDOs/Fora where documents are only available to members. I think
> this availability is a general issue and not just applicable the
> Megaco/H.248 work.      
> I think that it is a good thing that they may want to use
> Megaco/H.248, if they want to add packages in addition to what is
> already defined then for me this is OK. If those packages are
> applicable to the wider community then this is a comment that I think
> the IESG appointed expert can make and encourage the organisation to
> make it more widely available. This has occurred with 3GPP where they
> have proposed a 3GPP specific function but based on feedback have let
> the ITU produce a more general widely available solution. Another
> case was the MSF which was looking at standardising their own
> packages which would have been made available only to there members.
> On review and feedback it was pointed out that the packages in
> instances were incorrect and in other instances the packages were
> incorporated into ITU/ETSI documents. So in short, to this date we
> haven't had the "proprietary protocol"            
> issue and I don't think that the people/companies currently involved
> in the Megaco/H.248 standard would desire that this would happen. 
> 
>> -Pete
>> 
>> 
>> Christian Groves wrote:
>> 
>>> Hello Peter and Cullen,
>>> 
>>> implemented. The written description (pre this draft) doesn't
>>> actually match what is occurring. The draft also tries to set some
>>> review guidelines which again weren't documented. We have
>>> previously in the Megaco/H.248 work had cases where packages have
>>> been registered but basic things were missing or not well explained
>>> which have caused issues. By describing a review path we hope to
>>> pick these issues up before a package is fully registered.
>>> 
>>>> The existing procedures require the review to happen at IETF.
>>>> Almost all the work on this is actually happening at ITU right now
>>>> so we are trying to make it easier for the ITU folks get the
>>>> approvals they need done. We will select an expert reviewer that
>>>> is closely involved with the ITU folks working on this as they are
>>>> much more aware of all the ongoing work is and can catch
>>>> conflicts, duplicated efforts etc. 
>>>> 
>>>> process while at the same time helping improve the actual quality
>>>> of the review. 
>>>> 
>>>> Hope that helps.
>>>> 
>>>> Cullen
>>>> 
>>> http://www.ietf.org/liaisonActivities.html is this the list of
>>> (http://www.itu.int/ITU-T/lists/qualified.aspx#forums). This seems
>>> to be a more comprehensive list of organisations (i.e. it includes
>>>>> the designated expert, but it seems to allow that this
>>>>> specification isn't publicly available.  Should there be a
>>>>> requirement at least for public packages that the specification
>>>>> be public? 
>>>>> 
>>> organisation. The IETF is good that all documents are public but
>>> this doesn't apply to organisations such a MSF where the documents
>>> are available to the members but not the general public. So I don't
>>> think the draft can mandate that the package should be publicly
>>> available. 
>>> 
>>>>> Nits/editorial comments:
>>>>> 
>>>>> Section 1:
>>>>> OLD:
>>>>>   (i.e. the Error Code text and required specification) to the
>>>>> IESG appointed expert for review (See section 4.3). [CNG] OK
>>>>> 
>>>>> Section 5.3:
>>>>> OLD:

---

From: Christian Groves <[email-masked]>
Date: Tue, 31 Mar 2009 16:25:41 +1100

Hello Pete,

No worries about the delay as there was IETF meeting to deal with.

I don't think the fact that public and private packages have different 
ranges has been glossed over. This has been utilised by different 
registrations. You can see from the current registrations that private 
companies i.e. Ericsson, Nokia have registered packages in the "private" 
space.

I'm hesitant to mandate that unless the document is "publicly" available 
then the package must be registered in the "private" space. This is 
really due to the history of the protocol and the knowledge that the 
wording was like it was to allow membership based SDOs to have a 
different status from private companies. For instance if the ITU hadn't 
made Recommendations publicly available we'd now be proposing that their 
packages become "private" which I sure would have raised a few eye brows.

So from my perspective I would prefer to leave the current text because 
this aspect of public vs private and the availability of packages hasn't 
caused us trouble since the inception of the registry. What has caused 
trouble is the quality of the packages and in part that's what the draft 
is trying to address.

Regards, Christian

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 31 Mar 2009 10:43:58 -0400

Hi, Christian,

I can understand your point of view.  I am missing a lot of
history here and I wouldn't be upset to see the registry handled
as you suggest.  I'll let the IESG ponder the points I've raised
and let them make a decision.

-Pete

Christian Groves wrote:
> I don't think the fact that public and private packages have
> different ranges has been glossed over. This has been utilised by
> different registrations. You can see from the current registrations
> that private companies i.e. Ericsson, Nokia have registered packages
> in the "private"    
> space.
> 
> I'm hesitant to mandate that unless the document is "publicly"
> available then the package must be registered in the "private" space.
> This is really due to the history of the protocol and the knowledge
> that the wording was like it was to allow membership based SDOs to
> have a different status from private companies. For instance if the
> ITU hadn't made Recommendations publicly available we'd now be
> proposing that their packages become "private" which I sure would
> have raised a few eye brows.       
> 
> So from my perspective I would prefer to leave the current text
> because this aspect of public vs private and the availability of
> packages hasn't caused us trouble since the inception of the
> registry. What has caused trouble is the quality of the packages and
> in part that's what the draft is trying to address.    
> 
> Regards, Christian
> 
>> I am happy to let the IESG make a decision on whether or not to make
>> a distinction for "recognized" SDOs, and for availability of
>> specification.  I just wanted to make one point that may have been
>> glossed over: there is a distinction made between "public"
>> for the binary ID.  Would it be too much to ask that if a
>> specification is not publicly available at a stable URL, then the
>> package must be registered in the "private" space?
>> 
>> -Pete
>> 
>> Christian Groves wrote:
>> 
>>> Hello Peter,
>>> 
>>>> rules given in the draft mainly allow shorter codes to be
>>>> registered by these organizations.  Would it really harm the world
>>>> for an individual to register a package with a short name?  I can
>>>> imagine that some packages may become important even when not
>>>> developed by a "recognized standards organization".  Given the
>>>> review that needs to take place, we could easily guard against
>>>> squatting or spamming behaviors. 
>>>> 
>>>> 
>>> [CNG] I've addressed this point more in response to Cullen email.
>>> The original intention behind the split registry was that packages
>>>> a package without disclosing enough information for anyone to
>>>> produce an interoperable implementation.  The situation with H.248
>>>> right now is that I can go to the ITU website and download a copy,
>>>> which I think removed some of the qualms IETF may have had about
>>>> turning over change control from MEGACO to ITU.  I wouldn't want
>>>> to see H.248 turned into a proprietary protocol through the
>>>> extension mechanisms. 
>>>> 
>>>> 
>>> Megaco/H.248 work. I think that it is a good thing that they may
>>> want to use Megaco/H.248, if they want to add packages in addition
>>> to what is already defined then for me this is OK. If those
>>> packages are applicable to the wider community then this is a
>>> comment that I think the IESG appointed expert can make and
>>> encourage the organisation to make it more widely available. This
>>> has occurred with 3GPP where they have proposed a 3GPP specific
>>> function but based on feedback have let the ITU produce a more
>>> general widely available solution. Another case was the MSF which
>>> was looking at standardising their own packages which would have
>>> been made available only to there members. On review and feedback
>>> it was pointed out that the packages in instances were incorrect
>>> and in other instances the packages were incorporated into ITU/ETSI
>>> documents. So in short, to this date we haven't had the
>>> "proprietary protocol" 
>>>>> been registered but basic things were missing or not well
>>>>> explained which have caused issues. By describing a review path
>>>>> we hope to pick these issues up before a package is fully
>>>>> registered. 
>>>>> 
>>>>> Once we resolve the "recognised standards organisation" issue
>>>>> i'll provide an updated draft. 
>>>>> 
>>>>> Regards, Christian
>>>>> 
>>>>> Cullen Jennings wrote:
>>>>> 
>>>>> 
>>>>>> submit a draft to resolve theses - if some of them don't need to
>>>>>> be changed, just sort that on this email thread.
>>>>>> 
>>>>>> Almost all the work on this is actually happening at ITU right
>>>>>> now so we are trying to make it easier for the ITU folks get the
>>>>>> is closely involved with the ITU folks working on this as they
>>>>>> are much more aware of all the ongoing work is and can catch
>>>>>> This should make it easier to get things approved than the
>>>>>> current process while at the same time helping improve the
>>>>>> actual quality of the review. 
>>>>>> 
>>>>>> Hope that helps.
>>>>>> 
>>>>>> Cullen
>>>>>> 
>>>>>>> IETF LC End Date: 23 February 2009 IESG Telechat date: unknown
>>>>>>> 
>>>>>>> This document inserts an expert review procedure in the
>>>>>>> allocation policy for new H.248 packages/error codes/service
>>>>>>> change/profiles. This is probably a good thing but I have not
>>>>>>> been following the 
>>>>> from IETF thought "IETF Liaison relationship" and those from the
>>>>> ITU probably thought "Recognised Standards Development
>>>>> Organisation". I had a quick look at the IETF website and found:
>>>>> [CNG] I think this is really dependent on the rules of the
>>>>> standards organisation. The IETF is good that all documents are
>>>>> public but this doesn't apply to organisations such a MSF where
>>>>> the documents are available to the members but not the general
>>>>> public. So I don't think the draft can mandate that the package
>>>>> should be publicly available. 
>>>>> 
>>>>> 
>>>>>>> Nits/editorial comments:
>>>>>>> 
>>>>>>> Section 1:
>>>>>>> OLD:
>>>>>>>   2) The package requester shall provide a contact name, email
>>>>>>>   and postal addresses for that contact shall be specified.
>>>>>>> NEW:
>>>>>>>   5) Package names are allocated on a first come-first served
>>>>>>> basis if all
>>>>>>>   (Specification required) to the IESG appointed expert for
>>>>>>>   review (See section 4.3). NEW: On the request for an Error
>>>>>>>   Code registration, the IANA shall forward the received
>>>>>>>   information (i.e. the Error Code text and required
>>>>>>> specification) to the 
>>>>>>>   forward to received information (i.e. the Service Change
>>>>>>>   Reason text (Specification required) to the IESG appointed
>>>>>>> expert for